I vote for 2B combination. Someone else might need that script too so
it's a good idea to have it somewhere publicly available even it might
make the maintenance a little bit harder.
Have a nice day.
Lumír
On 10/11/22 11:47, Miro Hrončok wrote:
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?
_______________________________________________
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
