In build_scripts, unconditionally set shebang to #!python.#332
Conversation
jaraco
force-pushed
the
debt/unify-shebang
branch
from
ad516a6 to
eecd653
Compare
|
This seems to break the deprecated but still possible way of |
This is related to the discussion in pypa/setuptools#4883. My personal view is to prioritize non deprecated workflows. If the transition to non-deprecated workflows is not viable for all users that require such feature, I would welcome viable alternative approaches via PR contributions from the interested parties (which solve simultaneously the problem in pypa/setuptools#4863 and the one described in #332 (comment)). |
"setup.py install" is helplessly broken since setuptools v76: pypa/distutils#332 When we're at it, test "pip install" more thoroughly.
| ) | ||
| post_interp = shebang_match.group(1) or '' | ||
| shebang = "#!" + executable + post_interp + "\n" | ||
| shebang = f"#!python{post_interp}\n" |
There was a problem hiding this comment.
I believe this is the wrong approach. This code belongs to the build_scripts code, which may be invoked via the CLI, and even receives a executable argument, which is now explicitly ignored.
The #!python functionality is part of PEP 427, and as such, should be implemented in the wheel building code, not here.
There was a problem hiding this comment.
It seems bdist_wheel already implements this functionality itself, so the build_editable issue seems like a bug on the setuptools.build_meta backend. I believe fixing it should be as simple as setting executable there to python, just like bdist_wheel does.
There's a reason we have a In this case, it seems the change was exclusively motivated by a feature of the new backend, and it doesn't seem to me like there's a particular technical requirement for changes to the legacy code, so I can't see the justification for this approach. |
|
Im Fedora, we needed to revert this entirely. |
|
We've also reverted this change in the setuptools package in pkgsrc. |
This reverts commit 5589d75, reversing changes made to 250c300. Closes pypa/setuptools#4934
…version 80.3.1
Jason R. Coombs (25):
Remove reference in test_windows_wrappers to easy_install.
Moved some fixtures out of test_easy_install.
Moved scripts functionality into its own module.
Reference utility functions from _shutil.
Remove easy_install and package_index.
Revert "Merge pull request pypa/distutils#332 from pypa/debt/unify-shebang"
Remove support for special executable under a Python build.
In build_editable, ensure that 'executable' is hard-coded to #!python for portability.
Add news fragment.
Fix import.
Cast is unnecessary, apparently
Bump version: 80.1.0 → 80.2.0
Replace copy of license with an SPDX identifier. (jaraco/skeleton#171)
Add news fragment.
Update tests in setuptools/dist not to rely on Setuptools having a license file.
Rely on path.Path for directory context.
Add news fragment.
Bump version: 80.2.0 → 80.3.0
Moved pbr setup into a fixture.
Add a failing integration test. Ref #4976
Restore ScriptWriter and sys_executable properties.
Render the attributes dynamically.
Add the deprecation warning to attribute access.
Add news fragment.
Bump version: 80.3.0 → 80.3.1
5 participants
In the past, distutils then Setuptools was a (/the) primary installer for packages. It therefore took on the responsibility of rewriting Python shebangs in scripts.
Later, Setuptools became primarily a build backend and defers to installers (pip, uv, ...) to do the rewriting. Yet, the rewrite logic remained in Setuptools and leads to complications (see astral-sh/uv#2744).
This change removes that rewriting logic, replacing it with a static
#!pythonshebang to be rewritten by the installers.I note that the test suite continues to pass unchanged, so the legacy behavior is not captured in the tests. Furthermore, I don't personally install explicit scripts in any of my packages (as they tend to be non-portable). We'll need to find another way to validate the impact of this change.
Closes pypa/setuptools#4863.