On Mon, Dec 7, 2015 at 4:34 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 December 2015 at 17:07, Ronny Pfannschmidt > <opensou...@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 :) Thanks, Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
