On 5 February 2014 00:33, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
On Tue, 4/2/14, Paul Moore <p.f.moore@gmail.com> wrote:
The big problem with this type of thing is that pip tends to be used on lots of systems with sometimes *extremely* obscure and odd setups - what some of the Linux distros do to a standard Python install amazes me (I'm sure they have good reasons, of course...). So it's not so much a case of "scary dark corners" as lots of unanticipated and extremely difficult to reproduce use cases that we have to support but where the only knowledge of what workarounds are needed is encapsulated in the code.
You've just restated "scary dark corners" in a different way which sounds like there's more to it technically. But there' s still no hard data on the table!
http://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.htm... Vinay, please let it drop. Installing pip into every virtualenv works, and you haven't provided a concrete end user *benefit* for removing that layer of isolation - for upgrading pip after an upstream update to be burdensome, a user would need to both have a lot of virtual environments *and* fail to implement a script that automated the task of iterating over them all and upgrading pip. You accuse us of FUD, yet have presented no evidence that your approach works flawlessly across multiple versions of Fedora, Debian, openSUSE, RHEL, CentOS, Debian, Ubuntu, Windows, Mac OS X, etc, despite the fact that many distros are known to ship old versions of pip (and would likely end up shipping old system version of any new tool that performed a similar role, if they shipped it natively at all), and that pip used to have this feature, but it was removed due to the creation of hard to reproduce and debug scenarios. You yourself stated that end users would need to manage parallel installs of the virtualenv independent tool, since it would be designed not to be installed directly inside each virtualenv. And if it *was* intended to be installed inside virtualenv for parallel install support, then users would need to deal with the fact that sometimes it would be in the virtualenv and sometimes not. The status quo is simple, consistent, and comprehensible for developers and end users alike. If the other participants in *distutils-sig* think your suggested approach sounds confusing to use, what chance is there for end users? Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia