On Thu, Oct 8, 2009 at 9:52 AM, Michael Foord wrote:

Simon Cross wrote:

...

 On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé 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.

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 and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. I also use it as a sandbox for build bots so that multiple bots on the same machine can each build their own projects with just the known dependencies installed.

This is exactly why I use virtualenv as well. I don't recall ever having wanted / needed to install multiple versions of the same library - whilst I can appreciate that it *can* be a real issue it has never been a problem for me.

Michael

+1 - virtualenv, AFAIK is used for sandboxing/isolation of various environments, not dealing with multiple versions within the *same* environment. Of course, it does solve the "being dependent on a specific version" of a dependency because it *is* sandboxed from everything else. Adding multiple version support doesn't remove the need for sandboxing.

On Thu, Oct 08, 2009 at 04:28:52PM +0000, Antoine Pitrou wrote:

Toshio Kuratomi writes:

...

This is needing to install multiple versions and use the newly installed version for testing.

[...]

What you're missing is that having separate environments has a virtue of cleanliness, understandability and robustness that a multiple-versioned solution doesn't have. While the technical merits are debatable I'm sure some people definitely prefer to manage a virtualenv-based version.

I'm not missing it. I'm only saying that the precise requirement that is being stated is not sandboxing (that was listed later). It's being able to use a newly installed library for testing. The essential element of that is being able to install a new version of the library and use that instead of the sytem installed version. sandboxing may be how someone wants to do this but it isn't essential to be able to do this. -Toshio

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é 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

On Fri, Oct 9, 2009 at 1:35 AM, Masklinn 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

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)

...

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, this is the ability to not needlessly clutter site-packages, keep them clean, tight, focused; and the ability to keep a project's environment (such as its dependencies) clear and repeatable. Nowhere was it indicated that multiple versions were involved. Both of those *might* imply issues of multiple versions concurrently installed on the system, and virtualenv would incidentally solve these issues, but these issues are *not* the core of either use case. They're at best peripheral and potential