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

Toshio Kuratomi a.badger at gmail.com
Thu Oct 8 20:52:53 CEST 2009


On Thu, Oct 08, 2009 at 05:30:00PM +0100, Michael Foord wrote:
> Toshio Kuratomi wrote:
>> On Thu, Oct 08, 2009 at 02:52:24PM +0200, Simon Cross wrote:
>>   
>>>  On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>>>     
>>>> = Virtualenv and the multiple version support in Distribute =
>>>>       
>>> ...
>>>     
>>>> My opinion is that this tool exists only because Python doesn't
>>>> support the installation of multiple versions for the same
>>>> distributions.
>>>>       
>> Let's actually look at these reasons:
>>
>>   
>>> 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.
>>
>>   
>
> Not really - it is wanting to install a single version of a library that 
> you don't want to install into your 'main' (whether that be user or  
> system) Python install. It is sandboxing and orthogonal to multiple  
> versions.
>
What I'm replying to is specifically the need to: "become root whenever I
need to install a Python package for testing purposes" That doesn't require
sandboxing at all.  Can you use sandboxing to do this?  Yes.  But that is
separate to being able to install a non-system version of a library and be
able to test it.

My quoting of that phrase could have been better -- I missed the reference
to sandboxing since it is in a separate clause of the sentence from what I
was responding to.

>>>
>>> and to allow me to hop between
>>> sets of installed Python packages while developing on multiple Python
>>> projects.
>>>     
>>
>> This is the ability to install multiple versions and specify different
>> versions for different projects you're working on.
>>   
>
> No, it is working on multiple projects that have *different*  
> dependencies and being able to work in an environment that *only* has  
> direct dependencies installed - again sandboxed from your main Python  
> environment.
>
No. Here what is written is: "allow me to hop between sets of installed Python
packages while developing on multiple Python projects."

There's nothing about *only* having direct dependencies installed.  That's a
separate requirement than what was written.

> The fact that virtualenv allows you to have multiple different versions  
> of the same library installed in the different environments you create  
> is completely separate from the motivation that causes many people to  
> use it.
>
Precisely!  We see 100% eye-to-eye here.  My reply is just trying to say
that the ideas of
* testing a locally installed, conflicting version of a library
* running multiple projects with different, conflicting version requirements

are completely satisfiable without sandboxing.  Virtualenv is a sandboxing
tool.  It can be used to perform these tasks.  But it isn't necessary.
Having sandboxing is an additional feature on top of the base requirements
to perform the task.

> What virtualenv *doesn't* do (I believe) is allow you to have multiple  
> versions of libraries installed within a single environment and switch  
> between them (at least it doesn't offer anything beyond what setuptools  
> or pip provides).
>
Yep.  Which makes virtualenv unsuitable for certain other problem spaces
where sandboxing is inappropriate.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091008/41651a0c/attachment.pgp>


More information about the Python-Dev mailing list