Re: review for python-pgvector/0.4.2-1

Jeroen Ploemen <[email protected]> Wed, 4 Mar 2026 10:52:30 -0000
Newsgroups	gmane.linux.debian.devel.python
Message-ID	<[email protected]>
On Wed, 04 Mar 2026 07:24:58 +0000
Arian Ott <[email protected]> wrote:

Hi Arian,

thanks for making those improvements. First some new remarks:

* control: the binary pkg has a dependency on python3-sqlmodel, but
  that module appears to be used in the tests only.

* question: module dependencies on the binary package have been split
  into hard deps and recommended ones, although all import in the
  upstream code appear to be unconditional. What's the rationale here?


Then for some of the old findings:

> > * there's diff between the orig tarball pulled in by uscan and the
> >   one generated from the pristine-tar branch:
> >   (output from tardiff -m -s)
> > <snip>  
> 
> I recreated the pristine-tar again and pushed it in the repo.

Please push the updated pristine-tar and upstream branches. Tags also
seems to be missing on salsa, although they must exist given that the
commit messages on the master branch mention them; please push those
as well.

> > * autopkgtest: please test with all supported Python versions. The
> >   salsa CI logs show both 3.13 and 3.14 tested on build, but only
> >   3.13 in the autopkgtest.  
> 
> I added a for loop iterating over all python versions.

There seems to be a typo in that:
https://salsa.debian.org/python-team/packages/python-pgvector/-/jobs/9154762#L582

You want to inspect key CI steps (build, lintian, autopkgtest), even
if they got that green check-mark.

An error like that should have been fatal, but wasn't. That might be
the result of the entire code block within the pg_virtualenv not
running with 'set -e' (unlike the "main" script). Please make sure
the autopkgtest actually fails when things are broken, and check
whether or not the build-time tests are affected by this as well.

The autopkgtest also still carries a lot of excess dependencies. You
don't want to do that, as that can mask missing dependencies on the
binary package. Let the binary package take care of all runtime
requirements, and limit the dependencies on the autopkgtest to
whatever is needed on top of that to support the tests.

Note that this is fundamentally different from the situation during
build, where you don't yet have a binary package at your disposal and
therefore must list everything (including modules only needed at
runtime) as build-deps.

> Upstream rejected all patches ¯\_(ツ)_/¯

Too bad, thanks anyway for putting in the effort.
signature.asc (application/pgp-signature, 833 B)