Am 10.10.23 um 10:25 schrieb Matěj Cepl:
On Tue Oct 10, 2023 at 8:22 AM CEST, Daniel Garcia via openSUSE Factory wrote:
If you maintain a package that provides some python script, please,
consider to add this macro call.
Hi, Daniel,

I am sorry for not mentioning it before, but it was still
niggling in my head and I haven’t caught it on time: couldn’t
we somehow call this macro inside of our regular ones like
%pyproject_wheel or %pyproject_install (whereever it is more
apporpriate)? It seems unfair to lay another burden on our poor
package mainatainers.

Please see my comments in the PR, when I implemented this half a year ago. It's already part of %*pyproject_install.

https://github.com/openSUSE/python-rpm-macros/pull/155

It is called implicitly in %<flavor>_pyproject_install, but not in the deprecated %<flavor>_install. The latter would require more effort to implement, because adding lines to the macro would prevent the common pattern to append arguments directly after the currently parameterless macro.

In a %define pythons python3 build environment, %python3_fix_shebang creates the shebang with the resolved symlink where %{_bindir}/python3 points to. This is the only use case where the macro makes sense. When installing entry-points, Pip and Setuptools normally create the interpreter lines with the same interpreter as they are called by. Thus python3 setup.py install (from %python3_install) or python3 -mpip install ... would create a shebang pointing to python3, but the macro fixes it to the current primary interpreter (/usr/bin/python3.10).

It's also noteworthy that this macro is only really useful, if you use the singlespec macros with %python_subpackages for rewriting the Requires and %python_module for the BuildRequires tags. A package python3-foo (or just foo) directly defining a `Requires: python3-bar` package but using the %python3_fix_shebang macro will make things worse: If foo fails to rebuild at the time of the primary interpreter switch from python311 to python312, will require the old interpreter python3.11 through their hardcoded she-bang. But a sucessfully rebuilding python3-bar will move bar to the new python312 sitelib, out of reach from foo. So nothing gained by the new macro except that the interpreter and the foo module will fit together. Worse: If foo has just a script foobar.py using python3-bar bat not its own foo in sitelib, it will stop working through the move of bar. With generic python3 shebang the old installed script foobar.py would still work with the new python3-bar. Thus, it is rarely useful to explicitly use the macro. Those packages benefiting from it already do use it implicitly, or can be made to use it by switching from the deprecated %python_{build,install} to %pyproject_{wheel,install}. And for the others it makes things worse. - Ben