Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)

[Carles Pina i Estany <carles@pina.cat>]

Hi,

On 05 Oct 2023 at 16:36:17, Andrey Rakhmatullin wrote:
> On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote:
> > > upstream tests. Though I think it won't see your explicit `pytest -k` and
> > > you should replace the override with a PYBUILD_TEST_ARGS var.
> > 
> > Done this way:
> > https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43
> Now you don't need to override dh_auto_test, it should call pytest with
> correct args automatically.

Thanks, deleted and tested: all good. Doing something late night I
thought that PYBUILD_TEST_ARGS was only for the autopkgtest step and not
for the pytest run after the build.

> > pytest, as run automatically when having "Testsuite:
> > autopkgtest-pkg-pybuild": runs in the directory
> > "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing
> > "python3.11 -m pytest -k ...".
> > 
> > The contents of the directory via "ls -l" can be seen here:
> > https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357)
> This gives 404.

Apologies, for some reason, the settings of the repo was in Private.

The relevant URL for the "ls -l" that I mentiond is here:
https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L190

This is how I generated that output:
https://salsa.debian.org/carlespina/python-cloudscraper/-/commit/c8a01fca7bb8748da4529c57f2248db9ddb45bc7

> > Because there is the sub-directory
> > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper
> It shouldn't be there.

I think (and I see with one more package) that it's there if upstream
created a directory named PACKAGE_NAME in the root of the repository
(instead of doing src/PACKAGE_NAME). Which I think it's quite common, or
at least I've seen it other times.

I thought that I did something wrong with python-cloudscraper so I got
another random one (recently modified, and with the same layout). I
added these autopkgtests:
------
Test-Command: set -e ; pwd ; ls -l . airspeed; cd "$AUTOPKGTEST_TMP" ; python3 -c "import airspeed ; print(airspeed.__file__)"
Depends: python3-airspeed
Features: test-name=import-airspeed-system


Test-Command: set -e ; python3 -c "import airspeed ; print(airspeed.__file__)"
Depends: python3-airspeed
Features: test-name=import-airspeed-build
------

(seen here:
https://salsa.debian.org/carlespina/python-airspeed/-/commit/6ff20a68595be56101b63fbd4db720dee7c90ac9
)

The test with the "cd" to TMP: it imports the system wide airspeed:
"/usr/lib/python3/dist-packages/airspeed/__init__.py" (see the output of
the ls -l, airspeed, etc. and the airspeed.__file__ in
https://salsa.debian.org/carlespina/python-airspeed/-/jobs/4773820#L277
)

The test without the "cd" it imports the bundled one:
"/tmp/autopkgtest-lxc.yn973old/downtmp/build.9NT/src/airspeed/__init__.py"
(seen in
https://salsa.debian.org/carlespina/python-airspeed/-/jobs/4773820#L330)

That's why I did my work around of moving "cloudscraper" build directory
temporary before running autopkgtest. That lines in debian/rules:
----
before-pybuild-autopkgtest:
        mv cloudscraper $(AUTOPKGTEST_TMP)

after-pybuild-autopkgtest:
        mv $(AUTOPKGTEST_TMP) cloudscraper
----

> > : for what I can tell, pytest is running the tests with the code from
> > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper
> > and not the installed package in
> > /usr/lib/python3/dist-packages/cloudscraper/ . Generally speaking, I
> > prefer to use the installed code (as done via the basic "import").
> Sure, autopkgtests need to use the installed code.

I'm afraid that for some packages layout this is not happening. I am
happy to discuss it in another thread (I can open it). I think that,
meanwhile, the workaround using "before-pybuild-autopkgtest" in
debian/rules makes sense?

If I missed, or might have missed something let me know and I will dig
more...

Thanks for all the feedback!

-- 
Carles Pina i Estany
https://carles.pina.cat