[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