Hello Pythonistas,
The pathfix.py script has been removed from future Python 3.12:
https://discuss.python.org/t/remove-outdated-tools-scripts-scripts/19571
https://github.com/python/cpython/pull/98167
In Fedora, we package it to python3-devel as /usr/bin/pathfix.py and we use it
in:
%py3_shebang_fix
%pyproject_install
We also use it in python3.X %install section (directly from upstream source).
-------------------------
We have to decide what to do when we package python3.12 later this month.
How to ship the script:
1) We can take the script (and its tests) and add them as additional sources to
python3.12, carry on as we did before. The script was effectively only changed
upstream by us, so this does not really make a big difference.
Later on, when we have N identical scripts in python3.12, 3.13 ... and we need
to change things, we will need to do it in multiple places, but that has been
the case until now as well. It also allows us to gradually add improvements for
newer Pythons only.
This is the easiest solution in the short term.
2) We can add the script to the python-rpm-macros component instead and use one
script across all Python 3 versions. It seems easier to maintain that way, but
we would need to relocate the script outside of /usr/bin/ and invoke it from
the macros by `%{pytohn3} <script>`, instead of the shebenag, to avoid a direct
dependency on /usr/bin/python3 (to make it usable with different Python
versions and to build Python itself).
This is technically backwards incompatible and we would need to do this on
Rawhide+ only I guess. 35 packages BuildRequire /usr/bin/pathfix.py explicitly
(presumably for %py3_shebang_fix).
I believe this is the most proper solution long term.
3) We might try to package this as python3-pathfix into %{python3_sitelib}, but
I think it would be a really bad idea because we want to use it when building
Pythons and this would create an even more complex bootstrap loop. We also
allow using %py3_shebang_fix with various Python versions.
I'm not saying this way is not possible, but it feels wrong.
-------------------------
How to maintain the script "upstream":
A) We can put it in dist-git only. When we need changes in Fedora, we do them
directly where we need them.
This is the easiest solution in the short term.
B) We can create a project @ github.com/fedora-python and add CI etc. When we
need changes, we land them "upstream" first and let them propagate down or
backport them.
This requires some initial work and makes changes more tedious to land, but
theoretically allows easier 3rd party involvement and makes CI feedback-loop
shorter (no need to e.g. scratch build Python to test the package).
I believe this is the most proper solution long term.
C) Like B) but we also make it pip-installable adn upload to PyPI. Not sure if
worth it, but if we decide to go with 3) we will need to do this.
-------------------------
Alternatively, we might want to drop the script entirely and implement the
functionality from scratch with Lua/grep+sed/Rust/C instead to avoid the
Python-needs-Python problem.
WDYT?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
