Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
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?
Bug#1053413: RFP: tox-current-env -- tox plugin to run tests in current Python environment
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: tox-current-env Version : 0.0.11 Upstream Contact: Miro Hrončok * URL : https://github.com/fedora-python/tox-current-env * License : MIT Programming Lang: Python Description : tox plugin to run tests in current Python environment The tox-current-env plugin adds these options: tox --current-env Runs the tox testenv's commands in the current Python environment (that is, the environment where tox is invoked from and installed in). Unlike regular tox invocation, this installs no dependencies declared in deps. An attempt to run this with a Python version that doesn't match will fail (if tox is invoked from an Python 3.7 environment, any non 3.7 testenv will fail). tox --print-deps-to=FILE Instead of running any commands, simply prints the declared dependencies in deps to the specified FILE. This is useful for preparing the current environment for tox --current-env. Use - for FILE to print to standard output. tox --print-extras-to=FILE Instead of running any commands, simply prints the names of the declared extras in extras to the specified FILE. This is useful for preparing the current environment for tox --current-env. Use - for FILE to print to standard output. It is possible to use the two printing options together, as long as the FILE is different. Invoking tox without any of the above options should behave as regular tox invocation without this plugin. Any deviation from this behavior is considered a bug. The plugin disables tox's way of providing a testing environment, but assumes that you supply one in some other way. Always run tox with this plugin in a fresh isolated environment, such as Python virtualenv, Linux container or chroot. See other caveats below. Obviously, tox was created to run tests in isolated Python virtual environments. The --current-env flag totally defeats the purpose of tox. Why would anybody do that, you might ask? Well, it turns out that tox became too popular and gained another purpose. The Python ecosystem now has formal specifications for many pieces of package metadata like versions or dependencies. However, there is no standardization yet for declaring test dependencies or running tests. The most popular de-facto standard for that today is tox, and we expect a future standard to evolve from tox.ini. This plugin lets us use tox's dependency lists and testing commands for environments other than Python venvs. We hope this plugin will enable community best practices around tox configuration to grow to better accomodate non-virtualenv environments in general – for example, Linux distros, Conda, or containers. Specifically, this plugin was created for Fedora's needs. When we package Python software as RPM packages, we try to run the project's test suite during package build. However, we need to test if the software works integrated into Fedora, not with packages downloaded from PyPI into a fresh environment. By running the tests in current environment, we can achieve that. In my case, I want to avoid constantly downloading unverified code from the internet, or, even worse, *compile* code (e.g. for python3-ldap, in my case) which involves a whole other pile of stuff to install. Other Tox plugins are currently maintained by the Python team (and Peter Pentchev), so it would probably be the same for this one.
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
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. In the section just above your text (AUTOMATIC USAGE BY AUTOPKGTEST) it says: "autodep8 can be automatically called by autopkgtest(1). To achieve that, you must set the Testsuite: field in the source package paragraph to autopkgtest-pkg-TYPE," Because debian/control didn't have the line "Testsuite: " I thought that the rest of the text didn't really apply and I didn't expect the automatic "import" to happen (which I liked, not complaining!). In the next section: "autodep8 will first look for Testsuite: autopkgtest-pkg-TYPE field in debian/control. if TYPE is a known package type, then that is used. If not, each supported package type is tried against a set of heuristics,"... I read (yesterday) "if TYPE is a known package type, then that is used. If is not a known package type, then the heuristics..." Basically I had understood that I needed "Testsuite: autopkgtest-pkg-SOMETHING" (where SOMETHING is a non-supported one) to enable the automatic heuristics. But that "Testsuite: " line was required to enable it. Anyway, all clear on this front! Thanks very much! -- Carles Pina i Estany https://carles.pina.cat
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
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
