-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[BUG] setup.py install --prefix ...
uses easy_install -- breaks completely with setuptools 80+
#3143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
With pip about to deprecate eggs, I would really appreciate it if this behavior (causing eggs to be created for projects that have not created eggs with old distutils) could be fixed. |
Also fix setup.py invocation during make install. Ref: pypa/setuptools#3143
Also fix setup.py invocation during make install. Ref: pypa/setuptools#3143
This now breaks setup.py install completely: from setuptools import setup
setup(name='wtf', version='1')
|
distutils.core
-based setup.py install --prefix ...
uses easy_install -- brekas completely with setuptools 80+
distutils.core
-based setup.py install --prefix ...
uses easy_install -- brekas completely with setuptools 80+setup.py install --prefix ...
uses easy_install -- brekas completely with setuptools 80+
Maybe stating the obvious, but: running |
Oh, but we don't do this (at least not in the way that breaks) in Fedora. Upstreams do it in their Makefiles and we need to patch them to workaround that. Deprecated != broken. |
setup.py install --prefix ...
uses easy_install -- brekas completely with setuptools 80+setup.py install --prefix ...
uses easy_install -- breaks completely with setuptools 80+
It's interesting and surprising to me that setup.py install was affected by #2908, given that codebase was untouched. I'll revisit the codebase and see if I can come up with a solution. As the original issue above indicated, it was not ideal that 'install' triggered easy_install. I'm not sure what is the right approach here. |
Looking more closely, I see that codebase was touched... I think I confused that with being untested. I'll continue to investigate options. |
I'm currently considering one of two approaches:
A third option could be to do nothing and expect integrators to pin to setuptools<80 to build these legacy packages. |
I realized that |
For the record, this works:
So in my opinion, the proper fix here is to use the same codepath as if root is set. |
The reason setuptools/setuptools/command/install.py Lines 77 to 78 in 6c748ca
And I think I agree. Let's just remove the easy_install path and fall back to a simple distutils-based install (option 1). |
Instead of failing when easy_install isn't present. Closes #3143
Instead of failing when easy_install isn't present. Closes #3143
setuptools version
60.9.3
Python version
3.10.2
OS
Fedora Linux 35
Additional environment information
This is only happening with
SETUPTOOLS_USE_DISTUTILS=local
i.e. the default.Description
With a very simple setup.py script like this:
When I install the package with
python setup.py install --prefix <custom_value>
the installation warns me about missing support for .pth files, installation target not being on PYTHONPATH, easy_install deprecation and more. At the end, it produces an egg.This diverges from the expected behavior:
Expected behavior
The following happens with
SETUPTOOLS_USE_DISTUTILS=stdlib
:When the package actually has Python files in it, they are installed directly to site-packages instead of an egg.
This in fact replaces a deprecated tool (stdlib distutils) with another deprecated tool (easy_isntall), however in my opinion, the intention of the original code should be preserved. This creates unexpected results in Fedora, where packages that are wrapped in cmake end up installing different files then they epxected.
How to Reproduce
See above.
Output
See above.
The text was updated successfully, but these errors were encountered: