Hi,

I've uploaded my first package (python-cloudscraper). I've filled a RFS (#1053332). I have some questions (some specific to debian-python
organisation)

* Question 1: Git repo

I pushed the code to
https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I,
instead, push it already to https://salsa.debian.org/python-team/packages/python-cloudscraper/ ?

That might be related to Question 2.

* Question 2: debian/control, Maintainers and Uploaders

I've read https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership
and I think that my favourite, "long term" (does not need to be now),
would be:

Maintainer: Debian Python Team <team+python@tracker.debian.org>
Uploader: Carles Pina i Estany <carles@pina.cat>

So far I've done:
Maintainer: Carles Pina i Estany <carles@pina.cat>
And no Uploader (will be the sponsor on the first time).

Is that correct?

* Question 3: allow failing tests from upstream in dh_auto_test

Upstream has 4 failing unit tests. Besides working with upstream to fix
them what I've done is, in debian/rules:
-----
override_dh_auto_test:
# Disable tests failing from upstream
pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)"
-----

The reason is that I don't want to disable or even ignore failing unit
tests in the salsa-ci pipeline. If there is a new one failing I'd like
to know. The override_dh_auto_test is my way of having "allowed to fail"
for a specific list. Is there any other, better / recommended / standard
way?

* Question 4

Any casual comments on the package would be welcomed (even in a
non-sponsor level). For sponsoring: the main reason of packaging this is
that it's an indirect dependency of "simplemonitor". Related bugs:

RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113

Thank you,

--
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/2/23 09:11, Carles Pina i Estany wrote:

Hi,

I've uploaded my first package (python-cloudscraper). I've filled a RFS (#1053332). I have some questions (some specific to debian-python organisation)

* Question 1: Git repo

I pushed the code to
https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I,
instead, push it already to https://salsa.debian.org/python-team/packages/python-cloudscraper/ ?

Yes please.

That might be related to Question 2.

* Question 2: debian/control, Maintainers and Uploaders

I've read https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership
and I think that my favourite, "long term" (does not need to be now),
would be:

Maintainer: Debian Python Team <team+python@tracker.debian.org>
Uploader: Carles Pina i Estany <carles@pina.cat>

Yes. Note that not everyone in the team agree with the Python team
policy of having the team as Uploader, some, including myself, think
that if you don't want other people from the team to upload, you
shouldn't push the package to the team at all. YMMV...

So far I've done:
Maintainer: Carles Pina i Estany <carles@pina.cat>
And no Uploader (will be the sponsor on the first time).

Is that correct?

It's probably preferable to directly put the team as Maintainer.

* Question 3: allow failing tests from upstream in dh_auto_test

Upstream has 4 failing unit tests. Besides working with upstream to fix
them what I've done is, in debian/rules:
-----
override_dh_auto_test:
# Disable tests failing from upstream
pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)"
-----

The reason is that I don't want to disable or even ignore failing unit
tests in the salsa-ci pipeline. If there is a new one failing I'd like
to know. The override_dh_auto_test is my way of having "allowed to fail"
for a specific list. Is there any other, better / recommended / standard
way?

That's very good, and that's exactly what you should do, indeed: have as
many tests running as possible, so that you avoid regression. I would
also strongly suggest to use autopkgtest, to avoid that someone breaks
your package when uploading some of your dependencies.

* Question 4

Any casual comments on the package would be welcomed (even in a
non-sponsor level). For sponsoring: the main reason of packaging this is
that it's an indirect dependency of "simplemonitor". Related bugs:

RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113

Sorry, I wont have time for this right now, but if nobody does it, feel
free to ping me in a week or 2.

Cheers,

Thomas Goirand (zigo)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Thomas, list,

On 02 Oct 2023 at 14:11:54, Thomas Goirand wrote:

On 10/2/23 09:11, Carles Pina i Estany wrote:

Hi,

I've uploaded my first package (python-cloudscraper). I've filled a RFS (#1053332). I have some questions (some specific to debian-python organisation)

* Question 1: Git repo

I pushed the code to https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I, instead, push it already to https://salsa.debian.org/python-team/packages/python-cloudscraper/ ?

Yes please.

Done: https://salsa.debian.org/python-team/packages/python-cloudscraper/ (including the CI/CD setup)

That might be related to Question 2.

* Question 2: debian/control, Maintainers and Uploaders

I've read https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership
and I think that my favourite, "long term" (does not need to be now),
would be:

Maintainer: Debian Python Team <team+python@tracker.debian.org>
Uploader: Carles Pina i Estany <carles@pina.cat>

Yes. Note that not everyone in the team agree with the Python team policy of having the team as Uploader, some, including myself, think that if you don't want other people from the team to upload, you shouldn't push the package to the team at all. YMMV...

Changed. I didn't want to add the team in "Maintainer:" before double
checking with the team. I will do it straight away on the next package (python-pyaarlo, the other missing dependency of simplemonitor)

I will create a new version of the package and upload it into mentors.debian.net when I finish this email. For reference: it will be
the version 1.2.69-3.

So far I've done:
Maintainer: Carles Pina i Estany <carles@pina.cat>
And no Uploader (will be the sponsor on the first time).

Is that correct?

It's probably preferable to directly put the team as Maintainer.

:-) didn't want to impose it on my first attempt before seeing the
dynamic.

* Question 3: allow failing tests from upstream in dh_auto_test

Upstream has 4 failing unit tests. Besides working with upstream to fix them what I've done is, in debian/rules:
-----
override_dh_auto_test:
# Disable tests failing from upstream
pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)"
-----

The reason is that I don't want to disable or even ignore failing unit tests in the salsa-ci pipeline. If there is a new one failing I'd like
to know. The override_dh_auto_test is my way of having "allowed to fail" for a specific list. Is there any other, better / recommended / standard way?

That's very good, and that's exactly what you should do, indeed: have as
many tests running as possible, so that you avoid regression. I would also strongly suggest to use autopkgtest, to avoid that someone breaks your package when uploading some of your dependencies.

In my first version (not published) I wrote a simple autopkgtest with an "import cloudscraper" (I know that this is not fully testing everything
but at least something!). Then I realised that it's not needed...
without debian/tests it's just doing it:

https://salsa.debian.org/python-team/packages/python-cloudscraper/-/jobs/4762103#L180
"""
autopkgtest [22:24:36]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import cloudscraper; print(cloudscraper)" ; done
"""

I don't see this mentioned in "man autodep8": https://manpages.debian.org/testing/autodep8/autodep8.1.en.html (should
it be there?)

But it's done this way: https://salsa.debian.org/ci-team/autodep8/-/blob/master/support/python/generate#L78

* Question 4

Any casual comments on the package would be welcomed (even in a
non-sponsor level). For sponsoring: the main reason of packaging this is that it's an indirect dependency of "simplemonitor". Related bugs:

RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113

Sorry, I wont have time for this right now, but if nobody does it, feel free to ping me in a week or 2.

Very appreciated, I take note.

--
Carles Pina i Estany
https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:

I will create a new version of the package and upload it into mentors.debian.net when I finish this email. For reference: it will be
the version 1.2.69-3.

Note that the usual practice is not bumping Debian versions for packages
that were not uploaded yet and always uploading -1.

In my first version (not published) I wrote a simple autopkgtest with an "import cloudscraper" (I know that this is not fully testing everything
but at least something!). Then I realised that it's not needed...

Yeah.
And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run 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.

without debian/tests it's just doing it:

https://salsa.debian.org/python-team/packages/python-cloudscraper/-/jobs/4762103#L180
"""
autopkgtest [22:24:36]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import cloudscraper; print(cloudscraper)" ; done
"""

I don't see this mentioned in "man autodep8":

It says "each supported package type is tried against a set of heuristics, based on packages names, build dependencies. specific files under debian/,
or a combination of those", or do you mean something else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Andrey, list,

On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote:

On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:

I will create a new version of the package and upload it into mentors.debian.net when I finish this email. For reference: it will be
the version 1.2.69-3.

Note that the usual practice is not bumping Debian versions for packages
that were not uploaded yet and always uploading -1.

Note taken, thanks! It will stay in -1 until uploaded. Makes it even
easier.

In my first version (not published) I wrote a simple autopkgtest with an "import cloudscraper" (I know that this is not fully testing everything
but at least something!). Then I realised that it's not needed...

Yeah.
And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run

Ha! I didn't know of autopkgtest-pkg-pybuild. Thanks for this!

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

When I added it, the automatic simple test from autodep8 (importing the
module) stopped being added.

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)

Because there is the sub-directory /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/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").

Once, in a similar situation, some files were shipped but not installed
and the tests were running but not for the user.

So I still added this:
---
Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import cloudscraper" Depends: python3-cloudscraper
Features: test-name=import-cloudscraper
---
(simplified from the the original code done by autodep8)

without debian/tests it's just doing it:

https://salsa.debian.org/python-team/packages/python-cloudscraper/-/jobs/4762103#L180
"""
autopkgtest [22:24:36]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import cloudscraper; print(cloudscraper)" ; done
"""

I don't see this mentioned in "man autodep8":

It says "each supported package type is tried against a set of heuristics, based on packages names, build dependencies. specific files under debian/,
or a combination of those", or do you mean something else?

I read it differently / expressed myself badly :-(

TL;DR: I understood it now. I'm just explaining below what I had read
and understood wrongly.

Hi Andrey, list

On 03 Oct 2023 at 23:52:58, Carles Pina i Estany wrote:

On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote:

On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote:

I will create a new version of the package and upload it into mentors.debian.net when I finish this email. For reference: it will be the version 1.2.69-3.

Note that the usual practice is not bumping Debian versions for packages that were not uploaded yet and always uploading -1.

Note taken, thanks! It will stay in -1 until uploaded. Makes it even
easier.

In my first version (not published) I wrote a simple autopkgtest with an "import cloudscraper" (I know that this is not fully testing everything but at least something!). Then I realised that it's not needed...

Yeah.
And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run

Ha! I didn't know of autopkgtest-pkg-pybuild. Thanks for this!

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

When I added it, the automatic simple test from autodep8 (importing the module) stopped being added.

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)

Because there is the sub-directory /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/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").

Once, in a similar situation, some files were shipped but not installed
and the tests were running but not for the user.

So I still added this:
---
Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import cloudscraper"
Depends: python3-cloudscraper
Features: test-name=import-cloudscraper
---
(simplified from the the original code done by autodep8)

Recap: pytest executed from "pybuild-autopkgtest", in the
python-cloudscraper package, would use the src cloudscrapper instead of
the installed one.

So, to make sure that pytest uses the installed one, I added in
debian/rules:

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

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

https://salsa.debian.org/carlespina/python-cloudscraper/-/commit/c4ad00d05f9a7cf95c1c62d9fc791bf2cf0f222d

Then I could delete (seems redundant now) what I did last night (debian/tests/control):
-----
Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import cloudscraper" Depends: python3-cloudscraper
Features: test-name=import-cloudscraper
-----

Which was testing the import from the installed package.

Any thoughts?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

Because there is the sub-directory /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper

It shouldn't be there.

: 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 05 Oct 2023 at 16:38:29, Andrey Rakhmatullin wrote:

On Wed, Oct 04, 2023 at 07:58:11AM +0100, Carles Pina i Estany wrote:

Recap: pytest executed from "pybuild-autopkgtest", in the python-cloudscraper package, would use the src cloudscrapper instead of
the installed one.

So, to make sure that pytest uses the installed one, I added in debian/rules:

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

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

This looks very wrong, assuming it even runs.

Well, luckily $(AUTOPKGTEST_TMP) has no spaces :-) (I'll add " ")

Besides the lack of quotes: why does it look wrong? It's documented (or
this is how I understood it) in pybuild-autopkgtest(1), and it's
implemented in /usr/bin/pybuild-autopkgtest:
-------
$ENV{PYBUILD_AUTOPKGTEST} = "1";
if (system("grep -q ^before-pybuild-autopkgtest: debian/rules") == 0) {
doit($run, "before-pybuild-autopkgtest");
}
doit($run, "pybuild-autopkgtest");
if (system("grep -q ^after-pybuild-autopkgtest: debian/rules") == 0) {
doit($run, "after-pybuild-autopkgtest");
}
-------

Thanks!

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-python@lists.debian.org

Hi,

I've investigated a bit more and found where I was confused.

TL;DR: I'm deleting the non-needed workaround and found where things are happening.

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.

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.

Because there is the sub-directory /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper

It shouldn't be there.

They are not there if using all the automatic way. I was using at some
point a manual invocation of pytest and then things are not as nice :-)

So, using the automatic (generated via autodep8, etc.)...:

autodep8 generates:
----
Test-Command: pybuild-autopkgtest
Depends: @, pybuild-plugin-autopkgtest, @builddeps@,
Restrictions: allow-stderr, skippable,
Features: test-name=pybuild-autopkgtest
----

man pybuild-autopkgtest(1):
----
pybuild-autopkgtest will run the tests in exactly the same way as pybuild will dur‐
ing the build, with the exception that the tests are not run in the build directory.
The test files are copied to a temporary directory, so that the tests will run
against the installed Python modules, and not against anything in the source tree.
----

And yes, it happens in /usr/share/dh-python/dhpython/build/base.py

So, all good as long as pybuild-autopkgtest is used (and not pytest
invoked manually).

I'm happy deleting the d/rules workaround.

Cheers,

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEth6/Zob9uGYomaJ+qAKIT2ClX4EFAmUkj0oACgkQqAKIT2Cl X4FqsA/9EbkQp978T9TvuMe8b6l6IyJv5l6PrD48kzORv11wgoLmTeMMBwwn0a6Y i15kQgKdcGzCZS5owiObYQHxmGUHnAB678vh193g09dHd4Uafh2pdbsfaZZ1+h2I /L2ySB+LtGt+0cJ17CvdBH/vr/B9I0MZGZsNEdMCGWMUG3FyFFIxzggEjUCAk7CT I8aBJsXXo+4Dyyk+k9vGNrtID1h+SrUBwcJ95JGpfWItdqiodOH4P9Brs4Dm9Dhv 3Cl4bWOgD+b/sfA9RvufxGB8mdQhzVX8CF0zV8o6GdKr23ryOGBkHZRAHCt5O0mn /oJEHr7CJvbZxJwAfITUgbzDNz/nqvl1xOb4fhq7THBQgaIi2yWGiejpf3cQUgKF zhnVpbwVOmElRvlMD9LTRSlNOBKA9lZPLNYGLEvWULW118DXIVlBxaKGu0P4AZYo jCJUhmvzgL6xmJG/vSJwvxANzwxotCj+1+GHZPpnO2QJJJJtCWmh2iX1rZXXcwZX dCVMAVe8ScCNv/66mAQS9Cvtj60DP6lrn4bGLPGvB+2Uw/+bXDQJXpVTt4O59OE6 VskBJw8lebd/HFxYZ0ULbiqTIflVD1WjxDfOp9D3aAxLU7TFq2dqcrqMuuY6q3UI oGtoj+w97iWJh0+XZm8F74ZbxiWY9lh7YrSNEFvtb+rERLugGWY=
=bWg1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)