What is the purpose of virtualenv and why not install globally?

Question

What is the purpose of virtualenv and why not install globally?

Navigation

#1 by (9 votes)

8

I saw that VirtualEnv provides a way to create different environments for application development in Python . And, whenever we use it, you need to install the dependencies of a specific project.

For example, I realize that when it comes to projects like Django and the like, there is a strong recommendation to use this virtual environment.

But since I'm used to programming in PHP and I've never had a problem using the same PHP version for my projects, I started to wonder if it really is necessary or if the whole situation would be needed.

Because it seems that a Python version is installed, along with Pip and Easy install , for every Virtual Env created. In PHP, for example, we can only use the required dependencies in a project, using Composer , and use the PHP that is already installed to develop, in this case just stick to the details of the version used. >

So, I would like anyone who has experience greater than mine to explain with Python to me:

What are the strengths of using VirtualEnv?
Is there a case where I should not worry about using VirtualEnv?
Is it essential that in all project types I use VirtualEnv , or just conflicting cases?
Would not it be better to install everything globally instead of using VirtualEnv ? Whether you want it or not, it's an extra step in development.

python

asked by anonymous 04.05.2016 / 22:25

1 answer

What is the difference between DirectoryIterator and FileSystemIterator? Automatically post to Twitter from the PHP site

score 9 · Accepted Answer

Using VirtualEnv you isolate the dependencies of a project from those of others, some examples where this saves lives:

You work on multiple projects simultaneously, and some use the X version of a library while others use Y. This is very common, it may be that in a previous project you used the 1.1.x version of lib and in a new one (and this is also very common), in this scenario with VirtualEnv you can keep both working in parallel.

Your team develops software and maintains two repositories, a "trunk | edge | latest" where everything new is committed and another "stable" that is where the latest 100% tested version of the software stays. You on your local machine usually works on the "latest" but sometimes you need to take a look at "stable", it is very likely that you will eventually update libraries on the "latest", so without using VirtualEnv you can not run the two branches your software simultaneously because you will only be able to have a version of the libraries that they depend on installed globally on the system.

You have a server where you host various software for production. The older ones can use old versions of certain libraries, and you do not want to have to keep updating them, the stuff is in the air, it works and the customer is happy, why waste time stirring and risk breaking? with VirtualEnv all have their dependencies isolated, so the project that was done 2 years ago can continue running smoothly with the pre-historic version -0.0.1 of the X library, and the newer ones can use version 99 without drama. li>

As you can see the advantages are more accentuated when working with various softwares simultaneously. As a real-life example I usually have> 4 projects at the same time, everyone has to be running on my machine always, if the dependencies were installed globally it was going to be the complete chaos.

Another advantage of virtualenv is that, as you commented in the question, it can provide a separate version of the binaries themselves for python, pip and easy_install. This gives you an extra level of isolation, is little less useful than separating library versions but there are still cases where you want to use versions of these programs that are different from those installed on your operating system, as they may have dependencies on packages that would eventually mess up everything.

In the end it depends on your context, if you work on one python project at a time, it finishes and it nails it for eternity, you will not have problems installing everything globally, also if you only use a fixed version of python in all of them which is installed in your OS) there is no reason to create copies of it.