Description of problem: Python packages that require PyYAML < 6 or < 6.0 or < 6.0.0 produce the following RPM requirement: python3.10dist(pyyaml) < 6 PyYAML 6.0b1 produces the following provide: python3.10dist(pyyaml) = 6~b1 And 6~b1 is lesser than 6: $ rpmdev-vercmp '6~b1' '6' 6~b1 < 6 Hence packages that want "PyYAML < 6" are satisfied with 6.0b1, which does not happen with pip, where < 6 actually excludes any pre-releases of 6.0. $ pip install --pre 'pyyaml < 6' Installing collected packages: pyyaml Attempting uninstall: pyyaml Found existing installation: PyYAML 6.0b1 Uninstalling PyYAML-6.0b1: Successfully uninstalled PyYAML-6.0b1 Successfully installed pyyaml-5.4.1 Version-Release number of selected component (if applicable): python-rpm-generators-12-7.fc35 Additional info: I believe the Rust generators solve this by generating something like: python3.10dist(pyyaml) < 6~ I also think we have the same problem with packages that require > 6, as they would gladly accept 6.0.post1. In that case, we could probably generate: python3.10dist(pyyaml) > 6^zzz (Not nice, but 6^post > 6^^.)
> I also think we have the same problem with packages that require > 6, as > they would gladly accept 6.0.post1. In that case, we could probably generate: > > python3.10dist(pyyaml) > 6^zzz > > > (Not nice, but 6^post > 6^^.) Actually, 6.0 > 6^post, so we could generate: python3.10dist(pyyaml) > 6.0
I've added two patches to incorporate those suggestions: https://github.com/gordonmessmer/pyreq2rpm/pull/10 Once merged, I can sync the code up where it's used. Changes in pyreq2rpm/pyreq2rpm.py implement the suggested changes. Changes in tests/test_convert.py record the effects of the change. Changes in tests/test_requirement.py record improvements in fidelity between pip requirements and the generated rpm requirements. The suggested change for '<' resolve the previously documented problem with beta releases satisfying a requirement that they shouldn't, so that documentation of that quirk can be removed entirely. The suggested change for '>' improves fidelity between pip and rpm, but doesn't completely resolve it. It is still the case that a post release will satisfy a "> beta" release in the generated rpm requirements, which is not the case in pip: 2.4.8.post1 > 2.4.8b5 False 2.0.post1 > 2.0.0b5 False ... so that quirk remains exempted and documented in test_requirement.py.
> Once merged, I can sync the code up where it's used. Thanks! I will be mostly offline this week, but I have reviewed your PR and would gladly accept it in https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythondistdeps.py#_212 and https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/pyproject_convert.py#_103
PRs need a little work, but I'm also worried that upsteam change is incomplete after noticing the result of != in one of the test outputs: (python3dist(combo) < 3 or python3dist(combo) > 3) Should that also change to (python3dist(combo) < 3~ or python3dist(combo) > 3.0) ?
> Should that also change to (python3dist(combo) < 3~ or python3dist(combo) > 3.0) ? I think so, yes. Nice catch.
Or maybe not... >>> import pkg_resources >>> '2.4.8' in pkg_resources.Requirement.parse('foo!=2.4.8') False >>> '2.4.8post1' in pkg_resources.Requirement.parse('foo!=2.4.8') True >>> '2.4.8b1' in pkg_resources.Requirement.parse('foo!=2.4.8') True ...which seems weird, but as long as we're trying to model the real behavior of pkg_resources, then it seems like the current implementation is correct.
https://github.com/gordonmessmer/pyreq2rpm/pull/11 Prefix matching is a slightly different story, where we can make minor improvements. >>> import pkg_resources >>> '2.4.8b1' in pkg_resources.Requirement.parse('foo!=2.4.8') True >>> '2.4.8b1' in pkg_resources.Requirement.parse('foo!=2.4.8.*') False >>> '2.4.8post1' in pkg_resources.Requirement.parse('foo!=2.4.8.*') False In the case of prefix matching, (foobar < 2.4.8~ or foobar >= 2.4.9)' seems like an improvement over the current '(foobar < 2.4.8 or foobar > 2.4.9)'
Fixed in runtime generators on F36. Soon to be fixed in %pyproject_buildrequires as well.
I've just realized that 6.0-dev1 will be translated to 6~~dev1 which is still < 6~. Should we use < 6~~ instead?
Makes sense to me. I'll try to push changes again shortly.
I would've caught that sooner if the test suite had included dev releases, so: https://github.com/gordonmessmer/pyreq2rpm/pull/12
FEDORA-2021-a95b77dde1 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a95b77dde1
FEDORA-2021-6b65e8cc86 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6b65e8cc86
FEDORA-2021-b877063198 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b877063198` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b877063198 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6b65e8cc86 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6b65e8cc86` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6b65e8cc86 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a95b77dde1 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a95b77dde1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a95b77dde1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6b65e8cc86 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-b877063198 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-a95b77dde1 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.