On Thu, Nov 4, 2021 at 7:50 AM Miro Hrončok <mhron...@redhat.com> wrote: > > Hello Pythonistas. > > After some recent improvements in the Python RPM dependency generators, a > regression was discovered [0]. > > Turns out the error happened when the upstream metadata contained a > requirement > with a PEP 440 [1] incompatible version. A fix is pending and only one package > in Fedora was affected. > > However, this brings me to a question: What shall we do with such incompatible > versions in the future? Implementation-wise, the generators use the > pypa/packaging library to parse the requirements. When a PEP 440 incompatible > version is found, it's parsed as a LegacyVersion [3]. A LegacyVersion has been > deprecated for 1 year now and when found it might indicate a packaging > problem. > > I've experimented with a patched version of the generators that would error > out > right away when a LegacyVersion is parsed. I found the following categories of > problems: > > 1) A requirement uses invalid/legacy version (2 packages): > > python-celery: pytz>dev > > This is a pip-compatible shortcut for 0.dev.0, which is only required as a > hack > for PEP 440 incompatible versions of pytz from before 2013 (2012a, 2012b, > 2012c...). > > python-pvc: pyvmomi>=5.5.0-2014.1.1 > > This is an existing PEP 440 incompatible version of pyvmomi that has been > since > replaced with PEP 440 compatible version on PyPI. > > 2) The package itself has an invalid/legacy version (3 packages): > > python-haversion: main > python-ipmi: unknown > python-lacrosse: unknown > > This is most likely a packaging problem introduced by the Fedora packager by > using a GitHub tarball whereas the version information is only stored in > sdist. > I believe the generators should error out immediately when this happens to > prevent packaging errors, but there might be a need to allow it to proceed if > we want to package e.g. pyvmomi 5.5.0-2014.1.1 or pytz 2012d. > > > tl;dr: > > - there might be cases where legacy versions are needed > - but in most cases, they should be avoided > > Hence, I propose we do the following in Rawhide: > > We turn LegacyVersions to failures, but we provide a stop-gap measure, such as > (%global python_dependency_allow_legacy_version_provides 1 / %global > python_dependency_allow_legacy_version_requires 1 ) for packages that need to > override this. When pypa/packaging actually drops LegacyVersion, this stop-gap > measure will no longer work. > > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=2019954 > [1] https://www.python.org/dev/peps/pep-0440/ > [2] https://packaging.pypa.io/ > [3] > https://packaging.pypa.io/en/latest/version.html#packaging.version.LegacyVersion >
This makes sense to me, but would it also make sense to have some documentation about this case and how to resolve it to PEP 440 compatible versions, too? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
