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

Asked

Viewed 2,888 times

8

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

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

However, as I am used to programming in PHP and I never had problems using the same version of PHP for my projects, I started to wonder if it really is necessary or if the whole situation would be necessary.

Because, apparently, a version of Python is installed, along with Pip and Easy install, for each Virtual Env created. Already in PHP, we can for example only use the necessary dependencies in a project, through the 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’d like anyone with experience greater than mine Python explain to me:

  • What are the positives of using Virtualenv?

  • Is there a case where I shouldn’t worry about using Virtualenv?

  • It is essential that in all types of projects i use VirtualEnv, or only conflicting cases?

  • Wouldn’t it be better to install everything globally instead of using VirtualEnv? Because whether you want it or not, it’s a further step in development.

1 answer

10


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

  1. You work on multiple projects simultaneously, and some use X version of a library, while others use Y. This is quite common, may be that in a previous project you used lib version 1.1.x and in a new one you want to test 1.9.x which has 999 bug fixes but which may have something that worked before broken now (and this is also quite common), in this scenario with Virtualenv you can keep both running in parallel.
  2. His team develops a software and maintains two repositories, a "trunk|edge|Latest" where everything new is commited and another "stable" which is the one where the latest 100% tested version of the software is. You on your local machine usually work on "Latest" but sometimes need to take a look at "stable", it is very likely that eventually you will come to update libraries on "Latest"thus without using Virtualenv you cannot run both branches of your software simultaneously because you will only be able to have a version of the libraries they depend installed globally in the system.
  3. You have a server where you host various software for production. The older ones can use old versions of certain libraries, and you don’t want to keep updating them, the stuff is in the air, it works and the client is happy, why waste time stirring and risk breaking? with Virtualenv all have their dependencies isolated, so the project that was made 2 years ago can continue running smoothly with the prehistoric version -0.0.1 of the X library, and the newer ones can use version 99 without drama.

As you can see the advantages are more pronounced when working with multiple software simultaneously. As a real-life example I usually be in >4 projects at once, everyone has to be running for on my machine always, if the dependencies were installed globally it would be complete chaos.

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

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

  • good answer, thanks +1. In my case then, I have to use Virtualenv. The projects are in PHP, but if I ever migrate to Python, it’s 10 systems that I work on at the same time

  • In fact, if PHP doesn’t have a similar device, it only brings disadvantages - the amount of disk space that Virtualenvs use is negligible relative to the size of modern Hds - that would be the only disadvantage. Even so, it is still possible to install some packages on the system, and others distinct in each virtualenv, in some cases - just create virtualenv with the option --with-sytem-packages and packages like "ipython" or "ipdb" that are not really part of the projects can be shared.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.