Hello everyone,
with the upcoming Python 3.10 update we need to update Python 3 version globs in Fedora specfiles. The reason is simple, Python version will be one character longer so the currently omnipresent ?.? glob won't work anymore. We did this change a few months ago (see: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...), but we found out that the queries were incomplete, hence here is another update for the 3.? glob.
We will replace such globs with the %{python3_version} macro using:
$ sed -i -e 's/3.?/%{python3_version}/g' *.spec
There are currently 48 affected packages.
$ grep -l 'py3.?' *.spec | wc -l 48
The sed can theoretically produce unwanted changes, but when guarded by the grep, we have verified it won't. You can observe the general diff of all affected specfiles at https://github.com/hrnciar/rpm-specs/commit/7224a5.
We plan to do this in one week via a provenpackager. We will not bump the release number, nor add a changelog entry and hence we will also not rebuild the packages. The commit message will be:
Replace Python version glob with macro (needed for Python 3.10+)
If you want to fix this differently in your package, you don't need to let us know, just do it. If you want to opt out from this change, let us know (ideally with some reasoning). If you found a mistake in the diff, please do let us know.
Regards, Tomáš Hrnčiar
Maintainers by package: fonttools pnemade tagoh fusion-icon jskarvad marisa ueno nest ankursinha nototools mfabian pwu python-PyLEMS ankursinha python-bids-validator ankursinha python-brian2 ankursinha python-dipy ankursinha python-django-pytest bkabrda mrunge python-elasticsearch dbruno piotrp stevetraylen python-firehose athoscr dmalcolm python-fsleyes ankursinha python-fsleyes-props ankursinha python-fsleyes-widgets ankursinha python-fslpy ankursinha python-gccinvocation dmalcolm python-grabbit ankursinha python-httpretty jpopelka python-lazyarray ankursinha python-mpd2 ankursinha python-nilearn ankursinha python-nistats ankursinha python-petlink ankursinha python-pretend piotrp python-pybids ankursinha python-pyemd ankursinha python-pyfim ankursinha python-pylatex ankursinha python-pymatreader ankursinha python-pyphi ankursinha python-pyscaffold ankursinha python-pyzabbix piotrp python-rstcheck ankursinha python-simplewrap ignatenkobrain python-structlog piotrp python-tempdir rathann python-trollius iwienand mrunge python-tvb-data ankursinha python-tvb-gdist ankursinha python-tzlocal ankursinha piotrp python-vconnector raphgro python-whitenoise ngompa piotrp python-xdot dmalcolm rb_libtorrent fale mooninite simple-ccsm jskarvad vimiv ankursinha zanata-python-client anishpatil dchen jamesni pnemade robyduck seanf suanand
Packages by maintainer: anishpatil zanata-python-client ankursinha nest python-PyLEMS python-bids-validator python-brian2 python-dipy python-fsleyes python-fsleyes-props python-fsleyes-widgets python-fslpy python-grabbit python-lazyarray python-mpd2 python-nilearn python-nistats python-petlink python-pybids python-pyemd python-pyfim python-pylatex python-pymatreader python-pyphi python-pyscaffold python-rstcheck python-tvb-data python-tvb-gdist python-tzlocal vimiv athoscr python-firehose bkabrda python-django-pytest dbruno python-elasticsearch dchen zanata-python-client dmalcolm python-firehose python-gccinvocation python-xdot fale rb_libtorrent ignatenkobrain python-simplewrap iwienand python-trollius jamesni zanata-python-client jpopelka python-httpretty jskarvad fusion-icon simple-ccsm mfabian nototools mooninite rb_libtorrent mrunge python-django-pytest python-trollius ngompa python-whitenoise piotrp python-elasticsearch python-pretend python-pyzabbix python-structlog python-tzlocal python-whitenoise pnemade fonttools zanata-python-client pwu nototools raphgro python-vconnector rathann python-tempdir robyduck zanata-python-client seanf zanata-python-client stevetraylen python-elasticsearch suanand zanata-python-client tagoh fonttools ueno marisa
ankursinha nest python-PyLEMS python-bids-validator python-brian2 python-dipy python-fsleyes python-fsleyes-props python-fsleyes-widgets python-fslpy python-grabbit python-lazyarray python-mpd2 python-nilearn python-nistats python-petlink python-pybids python-pyemd python-pyfim python-pylatex python-pymatreader python-pyphi python-pyscaffold python-rstcheck python-tvb-data python-tvb-gdist python-tzlocal vimiv
Oooof! Please go ahead. Thanks very much.
Thank you python SIG for being transparent and helpful and thanks for making these commits. :)
kevin
Hello everyone,
I am just letting you know that we successfully replaced all 3.? globs yesterday.
Regards, Tomáš Hrnčiar
On Thu, Oct 29, 2020 at 02:05:53PM -0000, Tomas Hrnciar wrote:
Hello everyone,
I am just letting you know that we successfully replaced all 3.? globs yesterday.
Thanks! Both for doing it and the heads-up :)
Pierre
On Thursday, October 29, 2020 2:05:53 PM WET Tomas Hrnciar wrote:
Hello everyone,
I am just letting you know that we successfully replaced all 3.? globs yesterday.
Regards, Tomáš Hrnčiar
Thank you for doing that, and also for the previous round. But FWIW I still think that it would have been easier/better to rename python 3.10 to 4.0. ;-)
On 29 Oct 2020, at 17:29, José Abílio Matos jamatos@fc.up.pt wrote:
On Thursday, October 29, 2020 2:05:53 PM WET Tomas Hrnciar wrote:
Hello everyone,
I am just letting you know that we successfully replaced all 3.? globs yesterday.
Regards, Tomáš Hrnčiar
Thank you for doing that, and also for the previous round. But FWIW I still think that it would have been easier/better to rename python 3.10 to 4.0. ;-)
After the trauma of the 3.0 release it would be mad to do a python 4.0 for such a trivial reason as packagers that assumed, wrongly, that version can only have single digits.
Barry
-- José Abílio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
On Thu, Oct 29, 2020 at 10:49 PM Barry barry@barrys-emacs.org wrote:
After the trauma of the 3.0 release it would be mad to do a python 4.0 for such a trivial reason as packagers that assumed, wrongly, that version can only have single digits.
And/or codes did character comparisons on version values. I recall the same thing happened with the change from Solaris 5.9 to Solaris 5.10. What is old is new again (because 15 years is apparently too short a time to have actually learned the lessons).
On Thursday, October 29, 2020 10:49:27 PM WET Barry wrote:
After the trauma of the 3.0 release it would be mad to do a python 4.0 for such a trivial reason as packagers that assumed, wrongly, that version can only have single digits.
Barry
This now is an epistemological discussion. :-) I would not say that the assumption was wrong, IMHO it was right. People did not assume that version had a single digit they simply took what it worked. Because if you look back in history both python 1 and python 2 had only single digit so why should we add another level of complexity?
The same already happened before and in this case it affected python when the linux major version went from 2 to 3.
Because if we go to a defensive programming, as an example, we should always check the return value of printf (C/C++). There are places where it makes sense but in most places and in most cases that only makes the code longer, hard to read and hard to maintain.
And that was one of the reasons why there are projects changing from the semantic versioning to a scheme where only the major version number is relevant, e.g. gcc, octave, the browsers...
My original remark was on purpose ignoring that trauma, that in part was also self-inflicted, and joking about that. :-) After all this is one way to deal with trauma, or not? :-)
Regards,