Back in December I proposed adding an opt-in --pip option to ./setup.py install that will force using pip to install a package, rather than using easy_install. This would address existing requests to stop using easy_install by default for packages that use setuptools, without breaking backward compatibility where needed. The full proposal is here: https://mail.python.org/pipermail/distutils-sig/2015-December/027900.html
Individual projects can enable pip-installation by default by setting
[install]
pip = True
in their setup.cfg. Users may also install all projects with pip by default by setting the same in their pydistutils.cfg or equivalent. Of course, we should be discouraging ./setup.py install in the first place, but the idiom is stubbornly persistent in the wider Python universe. (A global setting would be somewhat dangerous as there are still some packages that won't install from pip at all, but they are less common).
It hasn't been discussed really since then that I can see, but had positive feedback at the time. I just didn't follow through with it due to the distraction of moving to a new country :)
The sample implementation I provided should be a good starting point. Still to be resolved is the issue of using pip for setup_requires as well, and will take a little more work.
I just wanted to post an issue so that the idea isn't lost. I intend to post a PR with tests soon.
Thank you for this great suggestion, it will solve a lot of easy_install related problems.
I'd like to see a fix for #250 before accepting a patch to use pip for installing packages, especially if individual packages are allowed to opt in to the behavior (limiting control by the user invoking the commands).
Maybe this needs to be discussed more. setuptools should use pip more.
For example, why it cannot use pip to resolve install_requires dependencies?
why it cannot use pip to resolve install_requires dependencies
I think that's what's being proposed here.
Yes, that's part of the idea here. More importantly, the point here is that by default projects that use setuptools use easy_install (as opposed to the vanilla 'install' command from distutils, or even anything resembling it). to implement the ./setup.py install command, which is now generally disfavored. This allows projects to opt in to ./setup.py install--which still has a lot of cultural cache--to be handled by pip instead.
@jaraco I'm not totally sure what the interaction is between this and #250 though I'm sure you have something in mind. Unless you're just saying you'd rather I spent my time fixing #250 in which case you probably have a good point there too :) Totally forgot about that one. Looks like it needs a patch in pip too (which actually might answer my first question).
I'm not totally sure what the interaction is between this and #250.
The interaction isn't specifically your involvement (though welcomed), but rather lessening the most egregious disparity between pip installs and easy_installs. I'd like to be at a place where I can comfortably recommend using pip exclusively, and #250 is the main blocker for doing so.
Sounds reasonable.
Anything new on this issue?
@petmakris I (or somebody) still needs to address #250 . I've been meaning to get to it. I might be able to this week if I get some other things out of the way first.
If someone else would like to take a stab at it, as I wrote here, I experimented with the second suggested fix here, with the simplification that in my experiments the lexicographic order for the .nspkg filename didn't matter.
If I rummage around I should still have a copy of the change I made somewhere, but I just never got around to outputting it as a patch!
(Part of the hold up is that I changed jobs earlier this year, and the work I was doing on setuptools was on my computer at my old job--I have everything backed up though so I just need to pull it up again. Fixing this is still definitely relevant to my interests.)
@pypa/setuptools-developers Hi!
With #250 resolved, is there interest in moving this forward? I do think setuptools should move the installations over to use pip more (maybe even exclusively, at some point in the future).
I am inclined to say that we should move forward with #917, but not implement this change.
My thinking is that we probably don't want people invoking setup.py install anyway, and they should be using pip install instead.