Hey folks,
We had a Python Team BoF at DC22 earlier today and I thought relaying the notes we took in gobby here would be a good idea.
----------------------------------------------------------------------
== python3.11 ==
python3.11 release has been delayed, from october 2022 to december 2022. [...]
== pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
We need people to test this MR some more, although it seems fairly mature.
It might be a good idea to have a line in d/control to let us migrate from the existing autopkgtests running unit tests to the new automated MR.
== lintian tags requests for the team ==
pollo will write you Python-related lintian tags. Ask him to.
== pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
We need people to test this MR some more, although it seems fairly mature.
It might be a good idea to have a line in d/control to let us migrate from the existing autopkgtests running unit tests to the new automated MR.
On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Vronneau wrote:
== pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27
We need people to test this MR some more, although it seems fairly mature.
It might be a good idea to have a line in d/control to let us migrate from the existing autopkgtests running unit tests to the new automated MR.
I've been looking at this a bit more. I'm not sure what this last
paragraph means: the new "automated" autopkgtest will only be run if
the maintainer explicitly adds:
Testsuite: autopkgtest-pkg-pybuild
to debian/control (see the autodep8 MR at https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs -
it will never automatically detect a pybuild package).
And a maintainer would presumably only add that if they are also
removing their existing debian/tests/control (or want to run the
pybuild tests in addition).
An alternative would be for the autodep8 patch to try to determine
whether to run pybuild-autopkgtest. One approach could be:
if the package would run autopkgtest-pkg-python:
if debian/control does not contain an override_dh_auto_test stanza:
run pybuild-autopkgtest
Note, though, that if autodep8 is called, it will run all of the
detected tests. (At least that is what I believe happens from reading /usr/bin/autodep8; I haven't double-checked this.) So, for example,
if a package specifies
Testsuite: autopkgtest-pkg-python
it will also run the autopkgtest-pkg-pybuild suite as it will be
detected as being a Python package, and vice versa. That is a
possible reason *not* to use the above suggestion, as it would
potentially run pybuild-autopkgtest even if not desired.
On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Véronneau wrote: >> > == pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27 >> >
We need people to test this MR some more, although it seems fairly mature. >> >
It might be a good idea to have a line in d/control to let us migrate from >> > the existing autopkgtests running unit tests to the new automated MR.
I've been looking at this a bit more. I'm not sure what this last
paragraph means: the new "automated" autopkgtest will only be run if
the maintainer explicitly adds:
Testsuite: autopkgtest-pkg-pybuild
to debian/control (see the autodep8 MR at
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs -
it will never automatically detect a pybuild package).
And a maintainer would presumably only add that if they are also
removing their existing debian/tests/control (or want to run the
pybuild tests in addition).
An alternative would be for the autodep8 patch to try to determine
whether to run pybuild-autopkgtest. One approach could be:
if the package would run autopkgtest-pkg-python:
if debian/control does not contain an override_dh_auto_test stanza:
run pybuild-autopkgtest
Note, though, that if autodep8 is called, it will run all of the
detected tests. (At least that is what I believe happens from reading
/usr/bin/autodep8; I haven't double-checked this.) So, for example,
if a package specifies
Testsuite: autopkgtest-pkg-python
it will also run the autopkgtest-pkg-pybuild suite as it will be
detected as being a Python package, and vice versa. That is a
possible reason *not* to use the above suggestion, as it would
potentially run pybuild-autopkgtest even if not desired.
I think the notes did not capture the consensus correctly. The point was
that it should be possible to automate updating the `Testsuite:` field
to run tests with pybuild-autopkgtest, and that we should probably do
that across team packages with the help of some scripting.
On July 26, 2022 2:50:19 PM UTC, Antonio Terceiro <terceiro@debian.org> wrote:
On Mon, Jul 25, 2022 at 09:04:27AM +0100, Julian Gilbey wrote:
On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Vronneau wrote: >> > == pybuild improvements ==
getting the autopkgtest MR in would be great
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27 >> >
We need people to test this MR some more, although it seems fairly mature.
It might be a good idea to have a line in d/control to let us migrate from
the existing autopkgtests running unit tests to the new automated MR.
I've been looking at this a bit more. I'm not sure what this last
paragraph means: the new "automated" autopkgtest will only be run if
the maintainer explicitly adds:
Testsuite: autopkgtest-pkg-pybuild
to debian/control (see the autodep8 MR at
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/27/diffs -
it will never automatically detect a pybuild package).
And a maintainer would presumably only add that if they are also
removing their existing debian/tests/control (or want to run the
pybuild tests in addition).
An alternative would be for the autodep8 patch to try to determine
whether to run pybuild-autopkgtest. One approach could be:
if the package would run autopkgtest-pkg-python:
if debian/control does not contain an override_dh_auto_test stanza:
run pybuild-autopkgtest
Note, though, that if autodep8 is called, it will run all of the
detected tests. (At least that is what I believe happens from reading
/usr/bin/autodep8; I haven't double-checked this.) So, for example,
if a package specifies
Testsuite: autopkgtest-pkg-python
it will also run the autopkgtest-pkg-pybuild suite as it will be
detected as being a Python package, and vice versa. That is a
possible reason *not* to use the above suggestion, as it would
potentially run pybuild-autopkgtest even if not desired.
I think the notes did not capture the consensus correctly. The point was >that it should be possible to automate updating the `Testsuite:` field
to run tests with pybuild-autopkgtest, and that we should probably do
that across team packages with the help of some scripting.
I suppose this is fine as long as whoever does it fixes all the resulting RC bugs.
Well the idea is to only actually commit the change and upload the
package with the new Testsuite value after ensuring that actually works,
i.e. that the autopkgtest passes.
On Tue, 2022-07-26 at 17:53 -0300, Antonio Terceiro wrote:
Well the idea is to only actually commit the change and upload the
package with the new Testsuite value after ensuring that actually works,
i.e. that the autopkgtest passes.
This sounds like something for lintian and the Janitor. I suggest
lintian because not all Python packages are in the team and I suggest
the Janitor because it makes changes automatically, although I am not entirely sure if it runs autopkgtests yet?
On Sat, Jul 23, 2022 at 07:52:19PM +0200, Louis-Philippe Véronneau wrote:
Hey folks,
We had a Python Team BoF at DC22 earlier today and I thought relaying the
notes we took in gobby here would be a good idea.
Thanks for the notes, Louis-Philippe, and sorry I couldn't join you!
A few comments....
----------------------------------------------------------------------
== python3.11 ==
python3.11 release has been delayed, from october 2022 to december 2022.
[...]
My 2 cents' worth is as the 3.9->3.10 transition took several months,
and was quite complicated, it is not wise to attempt the 3.10->3.11
before the freeze. We could then potentially go straight to 3.12 a
few months after the bookworm freeze rather than going to 3.11 first.
And that will probably be quite painful.
I think the notes did not capture the consensus correctly. The point was
that it should be possible to automate updating the `Testsuite:` field
to run tests with pybuild-autopkgtest, and that we should probably do
that across team packages with the help of some scripting.
There seems to be little point running both pybuild-autopkgtest and a manually written debian/tests/* test suite.
The way I see it:
1. We should have a Lintian tag for packages not using the new pybuild-autodep8 autopkgtest. It would be even better if this tag would be a pointed hint that identified 'manually' written unit test autopkgtests that could be replaced.
This way, you get something like:
python-foo source: not-using-pybuil-autodep8 [debian/tests/unittests]
for python packages that have old 'manually' written unit test autopkgtests and:
python-foo source: not-using-pybuild-autodep8 [no-autopkgtest]
for python packages without any autopkgtest.
2. lintian-brush (or something else, but I think lintian-brush is the right tool) would go over these packages to:
2.1 Add the new autodep8 autopkgtests and build the package to see if they pass
2.2 Remove the "manual" unit test autopkgtests if 2.1 succeeds
2.3 Open a bug report if 2.1 fails
On Wed, Jul 27, 2022 at 10:26:33AM -0400, Louis-Philippe Vronneau wrote:
The way I see it:
1. We should have a Lintian tag for packages not using the new pybuild-autodep8 autopkgtest. It would be even better if this tag would be a
pointed hint that identified 'manually' written unit test autopkgtests that could be replaced.
This way, you get something like:
python-foo source: not-using-pybuil-autodep8 [debian/tests/unittests]
for python packages that have old 'manually' written unit test autopkgtests and:
python-foo source: not-using-pybuild-autodep8 [no-autopkgtest]
for python packages without any autopkgtest.
2. lintian-brush (or something else, but I think lintian-brush is the right tool) would go over these packages to:
2.1 Add the new autodep8 autopkgtests and build the package to see if they pass
2.2 Remove the "manual" unit test autopkgtests if 2.1 succeeds
2.3 Open a bug report if 2.1 fails
I'd be wary about 2.2 and 2.3. I have several packages where I know
that an automated test will fail; there are all sorts of weird cases
where I've had to write tests manually. I would also be quite cross
if manually crafted tests were automatically removed, especially in
cases such as Simon mentioned where they do things that that
automatically generated test does not do. Another thing I could
imagine happening is that the automated test succeeds in a trivial way
- it succeeds but doesn't actually test much because of the nature of
the package.
On the other hand, a bug report saying something like the following
seems much more reasonable: "We've tested this package using the
automated autopkgtest system and it seems to work by adding the line 'Testsuite: autopkgtest-pkg-pybuild'; please check that the automated
tests cover all of the tests of your manually written debian/tests/*
and if so, then please remove them. The autopkgtest-pkg-pybuild logs
are attached." This would give the maintainer the chance to decide
how best to proceed.
[...]
I'd be wary about 2.2 and 2.3. I have several packages where I know
that an automated test will fail; there are all sorts of weird cases
[...]
I'd be wary about adding lintian tags for this, though: with so many
packages not being able to use the autodep8 system (I vaguely recall
someone suggesting that a third of Python packages would not be able
[...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 350 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:16:03 |
| Calls: | 7,625 |
| Files: | 12,793 |
| Messages: | 5,686,537 |