[Distutils] restart-in-venv

Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Feb 4 13:01:26 CET 2014


On Tue, 4/2/14, Nick Coghlan <ncoghlan at gmail.com> wrote:

> I've pointed out the technical problem with trying to rely solely
> on a global install on Linux: it makes it hard to use a newer version
> of pip than the OS provides. Installing pip into the virtual
> environments avoids that problem without conflicting with the
> OS package manager when it comes to the system Python
> installation.

> That decoupling from the distro version is a worthwhile technical
> benefit of the current approach. While it does mean that multiple
> virtual environments may need to be updated when a new version of pip
> is released, it *also* makes testing with different versions
> straightforward.
 
Well, it's not a bad thing IMO that distil leaves no trace of itself in a
venv, so no updating of any venv is required, were a new release of
distil to come out.

In terms of distro version isolation, I'm still not sure I get the practical
problem you're talking about, so let's get into specifics. In a parallel
universe, let's assume there's a tool that can install packages into
venvs, without needing to be installed into them first. (It seems a
desirable feature, which prompted the development of pip -E in the
first place). Let's say that this tool is shipped as part of a distro and
generally kept up to date by the distro's package manager.

Let's say that a new version of this tool is available upstream, but
not yet integrated into the distro, and that someone wants to use it
instead of the distro-supplied version. Where's the problem exactly?
It could just be a single file to download and run, and you could have
any number of different versions of it co-existing without any particular
problem. It needn't be any worse than any other type of tool where a
more-recent-than-distro version is desired.

I'm probably being dense, so perhaps you could outline any specific
problem scenarios along the lines of "a user wants to do X, but can't,
because of Y" where X is some aspect of installation / upgrading /
uninstallation of packages in a venv and Y is something which
intrinsically arises from the installation tool not being installed in the
venv. That would certainly help me understand where you're coming
from.

Regards,

Vinay Sajip


More information about the Distutils-SIG mailing list