Hello Pythonistas,
just a heads up that in rawhide, the automatically generated requirements on Python packages, e.g. python3.Xdist(DISTNAME), ar enow generated in more strict form.
If a package required "PyYAML < 6", it was previously generated as:
python3.10dist(pyyaml) < 6
Which was satisfied by PyYAML 6.0b1 (python3.10dist(pyyaml) 6~b1).
From now on, it will be generated as:
python3.10dist(pyyaml) < 6~
Which will not be satisfied by any alpha/beta/rc release of PyYAML 6.
There are other related differences as well neither of which should release break anything except for when dealing with pre-releases, it is now more strict. Details: https://bugzilla.redhat.com/show_bug.cgi?id=2014616
Any new requires will start happening as the packages are rebuilt, so as always, please check your packages for installability when you build them and let me know if something behaves in a weird way.
Identical changes to %pyproject_buildrequires will land soon (on all releases, as maintaining bit-by-bit requires compatibility is not necessary there).
Thanks to Gordon for improving the generators.
On 29. 10. 21 14:39, Miro Hrončok wrote:
From now on, it will be generated as:
python3.10dist(pyyaml) < 6~
Which will not be satisfied by any alpha/beta/rc release of PyYAML 6.
An only as I was typing this, I have realized that it won't work for dev releases, because 6~~dev1 < 6~ :(
https://bugzilla.redhat.com/show_bug.cgi?id=2014616#c9
Fortunately, we don't have that many dev releases packaged:
$ repoquery -q --repo=rawhide -a --provides | grep python3dist | grep '~~dev' python3dist(dictdiffer) = 0.1~~dev1 python3dist(mako) = 1.1.4~~dev0 python3dist(pcapy) = 0.11.5~~dev0 python3dist(pipx) = 0.16.4.1~~dev0 python3dist(podman-compose) = 0.1.7~~dev0 python3dist(pygments-markdown-lexer) = 0.1~~dev39 python3dist(quodlibet) = 4.5~~dev0 python3dist(sphinx-intl) = 2.0.1~~dev20210723 python3dist(tracmonotone) = 0.0.15~~dev20210704 python3dist(winpdb-reborn) = 2~~dev5 python3dist(yubikey-manager) = 4.0.8~~dev0
For some of them (e.g. mako), this seems to be a mistake even.
On 10/29/21 05:49, Miro Hrončok wrote:
For some of them (e.g. mako), this seems to be a mistake even.
There are a lot of "dev0" versions in that set, so I took a look for the cause. It looks like all of the "dev0" packages use github source rather than PyPI sources, which means that none of the release process defined in setup.py/cfg is being used for those packages; they're just tarballs of the git repo.
https://src.fedoraproject.org/rpms/python-mako/blob/rawhide/f/python-mako.sp...
"dev0" doesn't appear to be a bug in the scripts. Builds from github are intentionally marked dev releases:
https://github.com/sqlalchemy/mako/blob/main/setup.cfg#L72
That pattern also appears in the updated policy document:
https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x
I'd suggest that we should instead strongly encourage the use of PyPI URLs.
Am 30.10.21 um 21:42 schrieb Gordon Messmer:
I'd suggest that we should instead strongly encourage the use of PyPI URLs.
I agree that pypi downloads are usually preferable. However I had to use github tarballs sometimes as upstream did not ship the test suite for pypi tarballs...
Just my 2 ¢ Felix
On 10/30/21 13:12, Felix Schwarz wrote:
Am 30.10.21 um 21:42 schrieb Gordon Messmer:
I'd suggest that we should instead strongly encourage the use of PyPI URLs.
I agree that pypi downloads are usually preferable. However I had to use github tarballs sometimes as upstream did not ship the test suite for pypi tarballs...
Sure, "strongly encourage" isn't "require". There are cases where shipping the pypi tarball wouldn't meet Fedora's requirements, such as requiring the test suite to be present. But, conversely, the github tarballs also sometimes lack content that's in the pypi tarball, such as generated documentation.
In the past, where tests were not bundled with the pypi tarball, I've worked with the developers to fix their manifest so that it is, and that's worked out.
Almost all of the Python packages I maintain have something useful in the GitHub archive that isn’t in the PyPI archive. I find that PyPI source distributions commonly lack test suites and usually lack documentation. I choose PyPI sources where all else is equal, but in a lot of cases using GitHub sources is really the only reasonable option.
On Sat, Oct 30, 2021, at 3:42 PM, Gordon Messmer wrote:
On 10/29/21 05:49, Miro Hrončok wrote:
For some of them (e.g. mako), this seems to be a mistake even.
There are a lot of "dev0" versions in that set, so I took a look for the cause. It looks like all of the "dev0" packages use github source rather than PyPI sources, which means that none of the release process defined in setup.py/cfg is being used for those packages; they're just tarballs of the git repo.
https://src.fedoraproject.org/rpms/python-mako/blob/rawhide/f/python-mako.sp...
"dev0" doesn't appear to be a bug in the scripts. Builds from github are intentionally marked dev releases:
https://github.com/sqlalchemy/mako/blob/main/setup.cfg#L72
That pattern also appears in the updated policy document:
https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x
I'd suggest that we should instead strongly encourage the use of PyPI URLs. _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-leave@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.fedoraproje... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, Oct 30, 2021 at 8:42 PM Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/29/21 05:49, Miro Hrončok wrote:
For some of them (e.g. mako), this seems to be a mistake even.
There are a lot of "dev0" versions in that set, so I took a look for the cause. It looks like all of the "dev0" packages use github source rather than PyPI sources, which means that none of the release process defined in setup.py/cfg is being used for those packages; they're just tarballs of the git repo.
https://src.fedoraproject.org/rpms/python-mako/blob/rawhide/f/python-mako.sp...
"dev0" doesn't appear to be a bug in the scripts. Builds from github are intentionally marked dev releases:
https://github.com/sqlalchemy/mako/blob/main/setup.cfg#L72
That pattern also appears in the updated policy document:
https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x
I'd suggest that we should instead strongly encourage the use of PyPI URLs.
I disagree. PyPI is basically a packaging environment, so using the tarballs from there would mean we are then subject to the curation decisions by the people who package the PyPI releases before we even get the sources for the package (which may or may not be the upstream developers). Additionally, using the GitHub repo as the source of the package would seem to fit the spirit behind the packaging guidelines more ( https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/) - where it says "For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream."
-Ian
On 30. 10. 21 21:42, Gordon Messmer wrote:
On 10/29/21 05:49, Miro Hrončok wrote:
For some of them (e.g. mako), this seems to be a mistake even.
There are a lot of "dev0" versions in that set, so I took a look for the cause. It looks like all of the "dev0" packages use github source rather than PyPI sources, which means that none of the release process defined in setup.py/cfg is being used for those packages; they're just tarballs of the git repo.
https://src.fedoraproject.org/rpms/python-mako/blob/rawhide/f/python-mako.sp...
"dev0" doesn't appear to be a bug in the scripts. Builds from github are intentionally marked dev releases:
https://github.com/sqlalchemy/mako/blob/main/setup.cfg#L72
That pattern also appears in the updated policy document:
https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x
I'd suggest that we should instead strongly encourage the use of PyPI URLs.
That is however not always possible, see
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_fi...
I think we need to enhance that section with tips for when using a git tarball wrt setuptools_scm and tag_build = dev
See for example https://src.fedoraproject.org/rpms/python-mako/pull-request/13 (it doesn't even use git snapshot, but upstream release tarball).
On 10/31/21 02:45, Miro Hrončok wrote:
See for example https://src.fedoraproject.org/rpms/python-mako/pull-request/13
Would we upstream that? I think that the "staying close to upstream projects" policy suggests that we should. And, personally, I don't think we should patch source without at least asking the upstream project if that is the best solution.
In the case of mako, specifically, it probably isn't, since the PyPI tarball does include the test suite (and the generated documentation that's missing from the git tarball.)
(it doesn't even use git snapshot, but upstream release tarball).
In my opinion, calling it an "upstream release tarball" implies intent that is not in evidence. GitHub's release tarballs are a side-effect of declaring a release for a project that can't be disabled (last time I looked). For any project whose release process is more complex than simply tarring up the git repo (for example, any project that includes sub-modules in their intentional release archive), GitHub's automatic archive isn't a suitable substitute for the archive that developers intentionally publish.
On 31. 10. 21 19:21, Gordon Messmer wrote:
(it doesn't even use git snapshot, but upstream release tarball).
In my opinion, calling it an "upstream release tarball" implies intent that is not in evidence. GitHub's release tarballs are a side-effect of declaring a release for a project that can't be disabled (last time I looked). For any project whose release process is more complex than simply tarring up the git repo (for example, any project that includes sub-modules in their intentional release archive), GitHub's automatic archive isn't a suitable substitute for the archive that developers intentionally publish.
I've made a mistake when mentioning "upstream release tarball" because I've mistaken it with another package (sqlalchemy). It is not relevant here.
On 29. 10. 21 14:49, Miro Hrončok wrote:
On 29. 10. 21 14:39, Miro Hrončok wrote:
From now on, it will be generated as:
python3.10dist(pyyaml) < 6~
Which will not be satisfied by any alpha/beta/rc release of PyYAML 6.
An only as I was typing this, I have realized that it won't work for dev releases, because 6~~dev1 < 6~ :(
This has been fixed now. It will require:
python3.10dist(pyyaml) < 6~~
A bit ugly, but what appears to be a working solution.
As always, let me know if there is some unexpected trouble.
python-devel@lists.fedoraproject.org
-
Ben Beasley -
Felix Schwarz -
Gordon Messmer -
Ian McInerney -
Miro Hrončok