Skip to content
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

Closed
wimglenn opened this issue Nov 13, 2019 · 4 comments
Closed

get-pip.py still installs easy_install.py #7351

wimglenn opened this issue Nov 13, 2019 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@wimglenn
Copy link
Contributor

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:

Warning: Easy Install is deprecated. Do not use it. Instead use pip. If you think you need Easy Install, please reach out to the PyPA team (a ticket to pip or setuptools is fine), describing your use-case.

But, ironically, it's using get-pip.py or ensurepip that actually creates the unqualified bin/easy_install and the site-packages/easy_install.py in the first place. Probably get-pip.py and/or ensurepip 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?

@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Nov 13, 2019
@RonnyPfannschmidt
Copy link
Contributor

Unfortunately it is a part of setuptools and can't be avoided yet

@chrahunt
Copy link
Member

Hi @wimglenn! As @RonnyPfannschmidt said, this would be better directed towards setuptools. There is an outstanding PR to remove easy_install in pypa/setuptools#1830 and associated discussion in pypa/setuptools#917. I would contribute there if you can.

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.

@wimglenn
Copy link
Contributor Author

wimglenn commented Nov 14, 2019

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 get-pip.py itself could/should unlink it after creating it (checking, of course, that it was get-pip.py's own execution that created the file and it wasn't already present beforehand). Especially since you can't really retroactively remove it from an older bundled version of the setuptools installer.

@chrahunt
Copy link
Member

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.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Dec 14, 2019
@triage-new-issues triage-new-issues bot removed the S: needs triage Issues/PRs that need to be triaged label Dec 14, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Dec 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

3 participants