Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #13884 > unrolled thread

Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

Back to article view | Back to linux.debian.maint.python

Contents

  Reaching team consensus on usage of py3versions -r and  X-Python3-Version in Lintian Louis-Philippe Véronneau <pollo@debian.org> - 2022-01-17 18:50 +0100
    Re: Reaching team consensus on usage of py3versions -r and  X-Python3-Version in Lintian Sandro Tosi <morph@debian.org> - 2022-01-17 21:00 +0100
    Re: Reaching team consensus on usage of py3versions -r and  X-Python3-Version in Lintian Neil Williams <codehelp@debian.org> - 2022-01-18 09:20 +0100
      Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian Scott Kitterman <debian@kitterman.com> - 2022-01-18 14:10 +0100
    Re: Reaching team consensus on usage of py3versions -r and  X-Python3-Version in Lintian Thomas Goirand <zigo@debian.org> - 2022-01-18 15:40 +0100
      Re: Reaching team consensus on usage of py3versions -r and  X-Python3-Version in Lintian Julian Gilbey <jdg@debian.org> - 2022-01-19 20:30 +0100

#13884 — Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

[Multipart message — attachments visible in raw view] — view raw

Hey folks,

I'm following up on bug #1001677 [1] on the DPT's list to try to reach
consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.

As a TL;DR for those of you who don't want to read the whole BTS thread,
jdg saw that a bunch of packages were using `py3versions -r` in
autopkgtests, and this fails when there's no X-Python3-Version variable
in d/control.

The fix that Lintian now proposes for packages that use `py3versions -r`
in autopkgtests is to set X-Python3-Version.

I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.

As such, I think we should ask the Lintian maintainers to:

1. Change the desc for tag declare-requested-python-versions-for-test to

The specified test attempts to query the Python versions
<em>requested</em> by your sources with the command <code>py3versions
--requested</code> but your sources do not actually declare those
versions with the field <code>X-Python3-Version</code>.
.
Please query all <em>supported</em> Python versions with the command
<code>py3versions --supported</code> in your test instead.

2. Change the desc for tag query-requested-python-versions-in-test to

The specified test queries all <em>supported</em> Python versions with
the command <code>py3versions --supported</code> but your sources
request a specific set of versions via the field
<code>X-Python3-Version</code>.
.
Please delete the field <code>X-Python3-Version</code>, as it is not needed.


These changes would push maintainers to use `py3versions -s`, but
wouldn't ask people using `py3versions -r` and X-Python3-Version to make
any changes.

AFAIU, the only valid use of X-Python3-Version would be a package that
fails to build on an older but currently supported version of Python
(let's say 3.9) but builds on the newer version (say 3.10). I think such
use cases are pretty rare though.

Cheers,

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

[toc] | [next] | [standalone]

#13889

> I think the proper fix would be to ask people to move away from
> `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> -s` instead.
>
> As such, I think we should ask the Lintian maintainers to:
>
> 1. Change the desc for tag declare-requested-python-versions-for-test to
>
> The specified test attempts to query the Python versions
> <em>requested</em> by your sources with the command <code>py3versions
> --requested</code> but your sources do not actually declare those
> versions with the field <code>X-Python3-Version</code>.
> .
> Please query all <em>supported</em> Python versions with the command
> <code>py3versions --supported</code> in your test instead.
>
> 2. Change the desc for tag query-requested-python-versions-in-test to
>
> The specified test queries all <em>supported</em> Python versions with
> the command <code>py3versions --supported</code> but your sources
> request a specific set of versions via the field
> <code>X-Python3-Version</code>.
> .
> Please delete the field <code>X-Python3-Version</code>, as it is not needed.

+1

> AFAIU, the only valid use of X-Python3-Version would be a package that
> fails to build on an older but currently supported version of Python
> (let's say 3.9) but builds on the newer version (say 3.10). I think such
> use cases are pretty rare though.

maybe https://www.debian.org/doc/packaging-manuals/python-policy/#specifying-supported-versions
would need to be updated to clarify that the optional field is meant
to be used in exceptional circumstances (and state what they are
explicitly) and we generally expect the field to be absent.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#13890

[Multipart message — attachments visible in raw view] — view raw

On Mon, 17 Jan 2022 12:47:44 -0500
Louis-Philippe Véronneau <pollo@debian.org> wrote:

> Hey folks,
> 
> I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> consensus, as I think the Lintian tags that were created to fix this
> bug are not recommending the proper thing.
> 
> As a TL;DR for those of you who don't want to read the whole BTS
> thread, jdg saw that a bunch of packages were using `py3versions -r`
> in autopkgtests, and this fails when there's no X-Python3-Version
> variable in d/control.
> 
> The fix that Lintian now proposes for packages that use `py3versions
> -r` in autopkgtests is to set X-Python3-Version.
> 
> I think the proper fix would be to ask people to move away from
> `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> -s` instead.

Just as a general point, can I ask that - especially in a TL;DR - that
long option names are used or the context of each option is included as
the difference between -r and -s is not obvious from this email & not
everyone on the list uses py3versions routinely.

-- 
Neil Williams
=============
https://linux.codehelp.co.uk/

[toc] | [prev] | [next] | [standalone]

#13891 — Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, January 18, 2022 3:17:31 AM EST Neil Williams wrote:
> On Mon, 17 Jan 2022 12:47:44 -0500
> 
> Louis-Philippe Véronneau <pollo@debian.org> wrote:
> > Hey folks,
> > 
> > I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> > consensus, as I think the Lintian tags that were created to fix this
> > bug are not recommending the proper thing.
> > 
> > As a TL;DR for those of you who don't want to read the whole BTS
> > thread, jdg saw that a bunch of packages were using `py3versions -r`
> > in autopkgtests, and this fails when there's no X-Python3-Version
> > variable in d/control.
> > 
> > The fix that Lintian now proposes for packages that use `py3versions
> > -r` in autopkgtests is to set X-Python3-Version.
> > 
> > I think the proper fix would be to ask people to move away from
> > `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> > -s` instead.
> 
> Just as a general point, can I ask that - especially in a TL;DR - that
> long option names are used or the context of each option is included as
> the difference between -r and -s is not obvious from this email & not
> everyone on the list uses py3versions routinely.

TIL py3versions has long option names ...

  -d, --default    print the default python3 version
  -s, --supported  print the supported python3 versions
  -r, --requested  print the python3 versions requested by a build; the
                   argument is either the name of a control file or the value
                   of the X-Python3-Version attribute
  -i, --installed  print the installed supported python3 versions

Scott K

[toc] | [prev] | [next] | [standalone]

#13892

On 1/17/22 18:47, Louis-Philippe Véronneau wrote:
> Hey folks,
> 
> I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> consensus, as I think the Lintian tags that were created to fix this bug
> are not recommending the proper thing.
> 
> As a TL;DR for those of you who don't want to read the whole BTS thread,
> jdg saw that a bunch of packages were using `py3versions -r` in
> autopkgtests, and this fails when there's no X-Python3-Version variable
> in d/control.
> 
> The fix that Lintian now proposes for packages that use `py3versions -r`
> in autopkgtests is to set X-Python3-Version.
> 
> I think the proper fix would be to ask people to move away from
> `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> -s` instead.
> 
> As such, I think we should ask the Lintian maintainers to:
> 
> 1. Change the desc for tag declare-requested-python-versions-for-test to
> 
> The specified test attempts to query the Python versions
> <em>requested</em> by your sources with the command <code>py3versions
> --requested</code> but your sources do not actually declare those
> versions with the field <code>X-Python3-Version</code>.
> .
> Please query all <em>supported</em> Python versions with the command
> <code>py3versions --supported</code> in your test instead.
> 
> 2. Change the desc for tag query-requested-python-versions-in-test to
> 
> The specified test queries all <em>supported</em> Python versions with
> the command <code>py3versions --supported</code> but your sources
> request a specific set of versions via the field
> <code>X-Python3-Version</code>.
> .
> Please delete the field <code>X-Python3-Version</code>, as it is not needed.
> 
> 
> These changes would push maintainers to use `py3versions -s`, but
> wouldn't ask people using `py3versions -r` and X-Python3-Version to make
> any changes.
> 
> AFAIU, the only valid use of X-Python3-Version would be a package that
> fails to build on an older but currently supported version of Python
> (let's say 3.9) but builds on the newer version (say 3.10). I think such
> use cases are pretty rare though.
> 
> Cheers,
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677
> 

+1 (very much)

[toc] | [prev] | [next] | [standalone]

#13895

On Tue, Jan 18, 2022 at 03:37:13PM +0100, Thomas Goirand wrote:
> On 1/17/22 18:47, Louis-Philippe Véronneau wrote:
> > Hey folks,
> > 
> > I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> > consensus, as I think the Lintian tags that were created to fix this bug
> > are not recommending the proper thing.
> > 
> > As a TL;DR for those of you who don't want to read the whole BTS thread,
> > jdg saw that a bunch of packages were using `py3versions -r` in
> > autopkgtests, and this fails when there's no X-Python3-Version variable
> > in d/control.
> > 
> > The fix that Lintian now proposes for packages that use `py3versions -r`
> > in autopkgtests is to set X-Python3-Version.
> > 
> > I think the proper fix would be to ask people to move away from
> > `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> > -s` instead.
> > [...]

Dear all,

The lintian maintainers have indeed taken this suggestion on board and
have made most this change (modulo some minor wording differences):
the current wording is attached below.  I wonder whether with the use
of py3versions --supported with X-Python3-Version present, the message
should recommend removing the X-Python3-Version field as the preferred
option, as it does with the other case?


On some of the more general points, I scanned through every source
package in unstable and found the following:

* 6 packages use py3versions -d (--default) in their test suite; this
  is clearly an error in some packages (brial, ogre, sfepy, sinntp),
  and possibly an error in two others (numpy, scipy) - I haven't
  looked in detail at the last two

* Quite a few packages use py3versions -i (--installed) in their test
  suite; this is almost certainly wrong (though it probably does the
  right thing in an autopkgtest if it depends on python3-all)

As far as X-Python3-Version goes:

* 5 packages have X-Python3-Version: ${python3:Versions}, which is
  surely wrong?

* 2 packages have commented-out X-Python3-Version lines; these could
  probably just be removed

* about 166 packages have X-Python3-Version: >= 3.x, where 0 <= x <=
  3.7.  All of these packages would work in oldstable (buster) or
  later without this line

* 8 packages have >= 3.8 and 3 packages have >= 3.9; these would work
  in stable (bullseye) or later without this line

* 6 packages have just 3.9 (calibre, pytorch-audio, pytorch-ignite,
  pytorch-text, pytorch-vision, skorch); these will no longer work in
  testing (bookworm) once Python has fully migrated to 3.10.

* 6 packages have "all" or "current"; I have filed bug reports on
  these.

So of the entire archive, only 6 packages have a correct and current
use of X-Python3-Version.


Here is the current Lintian wording:

For use of py3versions --requested/-r without a corresponding
X-Python3-Version:
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/d/declare-python-versions-for-test.tag

Tag: declare-python-versions-for-test
Severity: warning
Check: testsuite
Renamed-from:
 declare-requested-python-versions-for-test
Explanation: The specified test attempts to query the Python versions
 <em>requested</em> by your sources with the command
 <code>py3versions --requested</code> but your sources do not declare
 any versions with the field <code>X-Python3-Version</code>.
 .
 Please choose between two suggested remedies:
 .
 In most circumstances, it is probably best to replace the argument
 <code>--requested</code> with <code>--supported</code>. That will
 exercise the test with all available Python versions.
 .
 Should your installable require only specific Python versions, please add
 the field <code>X-Python3-Version</code> with the appropriate information
 to the source stanza in the <code>debian/control</code> file.
 .
 No redirection of the output, as in <code>2 &gt; /dev/null</code>, is
 needed in either case.
See-Also:
 py3versions(1),
 Bug#1001677


For the use of py3versions --supported/-s with the presence of
X-Python3-Version (a rare occurrence):
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/q/query-declared-python-versions-in-test.tag

Tag:  query-declared-python-versions-in-test
Severity: warning
Check: testsuite
Renamed-From:
 query-requested-python-versions-in-test
Explanation: The specified test queries all <em>supported</em> Python versions
 with the command <code>py3versions --supported</code> but your sources request
 a specific set of versions via the field <code>X-Python3-Version</code>.
 .
 Please query only the requested versions with the command
 <code>py3versions --requested</code>.
See-Also:
 py3versions(1),
 Bug#1001677


Best wishes,

   Julian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web