[Distutils] setup.py install using pip

Erik Bray erik.m.bray at gmail.com
Mon Dec 7 11:21:42 EST 2015

On Mon, Dec 7, 2015 at 4:34 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 7 December 2015 at 17:07, Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de> wrote:
>> That's a straw man, this has enough inconsistency potential to break many
>> edge cases in ugly ways,
>> So global setup is out.
> No, global set up *isn't* out - the inevitable edge cases won't matter
> to an application integrator if none of the components they're using
> hit them, and installation related problems have the virtue of being
> relatively straightforward to pick up in a continuous integration
> system.
> Using such a switch wouldn't be the right fit for everyone, but that's
> not the same as it being entirely useless.

Exactly--as both a library developer / maintainer and system
integrator I would find such a flag very useful (especially since I
can just set it in a config file and forget it).  It would be right
for me.  But wouldn't break anything for anyone else.

Ironically, the default behavior of `setup.py install`, on projects
that use setuptools, is to install an egg directory which is
*definitely* not for everybody, especially not anymore.  That's why
--single-version-externally-managed exists.  A --pip flag would be
very much like --single-version-externally-managed (sort of a
specialized extension of it) that also includes "do everything pip
does" which includes installing dependencies and copying
.egg-info/.dist-info to the appropriate location, which is what I want
to replace all instances of `setup.py install` with.  That includes
users running `setup.py install`, who have a hard enough time as it is
keeping up with Python build/installation "best practices" as it is.

Anyways, it has been frequently requested that setuptools change the
default behavior of the "install" command, so I wouldn't discount it
as a valid use case.  So far it hasn't been changed out of
backward-compat concerns, so making it loosely opt-in represents a
possible middle ground.

>> Projects themselves can really just switch to pip commands, same goes for
>> packagers and other tool makers
>> Explicit is better than implicit, and in this case it also won't cost
>> additional maintenance on setuptools.
>> Please keep in mind, that setuptools is completely on volunteer time, and
>> the time given to it is scarce.
> Sure, that's why any decision on the desirability of this feature
> would be up to Jason as the setuptools lead. However, there's a
> trade-off to consider here, which is that offering this kind of global
> installer switch may help to lower the priority of some other
> easy_install enhancement requests.

Plus I've contributed to setuptools many times in the past (used to
have commit access on distribute too).  I'm offering to implement and
maintain this feature if it's decided desirable.  I think it *is*
desirable by definition--I desire it, and I suspect others would as
well.  I'd be more interested in technical reasons why it's a bad idea
but I haven't found any yet.

> That's a risk assessment trade-off on future bug reports against
> attempted pip support vs future RFEs against easy_install itself, as
> well as a priority assessment against other open changes proposed for
> setuptools. Those assessments may well come down on the side of "not
> worth the hassle", but the scope of the proposed change still falls a
> long way short of being a "maintenance horror".

I think the only maintenance horror right now is easy_install :)


More information about the Distutils-SIG mailing list