[Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

[Nick Coghlan]

On 5 February 2014 00:33, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> On Tue, 4/2/14, Paul Moore <p.f.moore at 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.html

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 at gmail.com   |   Brisbane, Australia