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.ta...@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
pgpzP7TagU4bO.pgp
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
