-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
get-pip.py still installs easy_install.py #7351
Comments
Unfortunately it is a part of setuptools and can't be avoided yet |
Hi @wimglenn! As @RonnyPfannschmidt said, this would be better directed towards setuptools. There is an outstanding PR to remove I hope that helps! I will close this now, but please feel free to drop a link to any other discussions you find so interested people can follow. |
Yes, I understand it is the responsibility of setuptools to stop generating the script (and looks like it's well underway in #1830), I was just wondering if |
I don't think we would want to make that decision for setuptools or its users. You can see we have a lot on our hands trying to deprecate our own scripts in #3164, and that has already been some time. :) When that PR gets merged (and a release happens) it should get pulled into the next update to get-pip, which usually happens with pip releases. |
Nobody should use
easy_install
these days. It's not needed, might make a mess of your system if you don't know what you're doing, and it's too hard to type the underscore ;)Even setuptools docs now says to use pip instead:
But, ironically, it's using
get-pip.py
orensurepip
that actually creates the unqualifiedbin/easy_install
and thesite-packages/easy_install.py
in the first place. Probablyget-pip.py
and/orensurepip
should stop doing it by default to avoid the foot gun. Or maybe it should just be removed from setuptools installer, which would mean no extra job for pip after the vendored versions in _bundled are next bumped.Thoughts?
The text was updated successfully, but these errors were encountered: