Bug#1004746: lintian: provide a check for Python package version numbers validity
On Thu, Jul 14, 2022 at 09:02:40AM +0100, Julian Gilbey wrote: > On Tue, Feb 01, 2022 at 07:57:58PM +0500, Andrey Rahmatullin wrote: > > On Tue, Feb 01, 2022 at 02:45:21PM +, Julian Gilbey wrote: > > > I just hit two packages which gave me the following warning when > > > pkg_resources tried to load them: > > > > > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: > > > PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is > > > an invalid version and will not be supported in a future release > > > warnings.warn( > > This looks strange to me. I wouldn't expect the package version > > (especially with the Debian part) to be there. > > I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`, > > I don't know why, or whether this is a good idea. > > Some updates on this: > > * The version information can also appear in > /usr/lib/python3/dist-packages/*.dist-info/METADATA > * The upstream standard is defined in PEP 440: > https://peps.python.org/pep-0440/ > > I agree, flatbuffers is doing weird stuff. > > Best wishes, > >Julian A further update: a package with this type of bug recently caused an RC error, as it prevented other packages from loading: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036947 So if this check is implemented, it should probably raise an lintian Error if a package fails this check. (The related feature request #1005043 should probably only raise a warning.) Best wishes, Julian
Bug#1004746: lintian: provide a check for Python package version numbers validity
On Tue, Feb 01, 2022 at 07:57:58PM +0500, Andrey Rahmatullin wrote: > On Tue, Feb 01, 2022 at 02:45:21PM +, Julian Gilbey wrote: > > I just hit two packages which gave me the following warning when > > pkg_resources tried to load them: > > > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: > > PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an > > invalid version and will not be supported in a future release > > warnings.warn( > This looks strange to me. I wouldn't expect the package version > (especially with the Debian part) to be there. > I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`, > I don't know why, or whether this is a good idea. Some updates on this: * The version information can also appear in /usr/lib/python3/dist-packages/*.dist-info/METADATA * The upstream standard is defined in PEP 440: https://peps.python.org/pep-0440/ I agree, flatbuffers is doing weird stuff. Best wishes, Julian
Bug#1004746: lintian: provide a check for Python package version numbers validity
On Tue, Feb 01, 2022 at 02:45:21PM +, Julian Gilbey wrote: > I just hit two packages which gave me the following warning when > pkg_resources tried to load them: > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: > PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an > invalid version and will not be supported in a future release > warnings.warn( This looks strange to me. I wouldn't expect the package version (especially with the Debian part) to be there. I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`, I don't know why, or whether this is a good idea. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1004746: lintian: provide a check for Python package version numbers validity
Package: lintian Version: 2.114.0 Severity: wishlist X-Debbugs-Cc: Debian Python Team I just hit two packages which gave me the following warning when pkg_resources tried to load them: /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an invalid version and will not be supported in a future release warnings.warn( (and a different version number in the other case). The upstream Python developers have a clear idea of what is accepted as a version number, and it appears in /usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py (in the python3-pkg-resources package) in the definition of VERSION_PATTERN. The version number that is being examined is that stored in /usr/lib/python3/dist-packages/*.egg-info or /usr/lib/python3/dist-packages/*.egg-info/PKG-INFO on the line beginning "Version: ". This appears to be a fairly rare bug: only two packages on my system have this issue (and I've just reported bugs against them). Nonetheless, if it is easy, it would be nice to have a lintian test for it. Best wishes, Julian
