[Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

David Cournapeau cournape at gmail.com
Thu Oct 8 19:22:32 CEST 2009


On Fri, Oct 9, 2009 at 1:35 AM, Masklinn <masklinn at masklinn.net> wrote:
> On 8 Oct 2009, at 18:17 , Toshio Kuratomi wrote:
>>
>>> This is not at all how I use virtualenv. For me virtualenv is a
>>> sandbox so that I don't have to become root whenever I need to install
>>> a Python package for testing purposes
>>
>> This is needing to install multiple versions and use the newly installed
>> version for testing.
>>
> No it's not. It's keeping the python package *being tested* out of the
> system's or user's site-package because it's potentially unstable or
> unneeded. It provides a trivial way of *removing* the package to get rid of
> it: delete the virtualenv. No trace anywhere that the package was ever
> installed, no impact on the system  (apart from the potential side-effects
> of executing the system).
>
> The issue here isn't "multiple installed packages", it will more than likely
> be the only version of itself: note that it's a package being tested, not an
> *upgrade* being tested.
>
> The issues solved are:
> * not having to become root (solved by PEP 370 if it ever lands)
> * minimizing as much as possible the impact of testing the package on the
> system (not solved by any other solution)

This is not true - stow solves the problem in a more general way (in
the sense that it is not restricted to python), at least on platforms
which support softlink. The only inconvenience of stow compared to
virtual env is namespace packages, but that's because of a design flaw
in namespace package (as implemented in setuptools, and hopefully
fixed in the upcoming namespace package PEP).

Virtualenv provides a possible solution to some deployment problems,
and is useful in those cases, but it is too specialized to be included
in python itself IMO.

cheers,

David


More information about the Python-Dev mailing list