Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Where should virtualenvs go in production?

When using virtualenv (or virtualenvwrapper), the recommended practice is to group all your virtual environments together ... for example in ~/.virtualenvs

BUT, I've noticed in reading a number of articles on deploying Django applications, that the recommendation seems to be to put your virtual environments somewhere under the root of the individual web application ... for example in /srv/www/example.com/venv.

My questions are:

  1. Why?

  2. Would it matter if I went one way or the other?

  3. And is one way recommended over another?

like image 817
wgpubs Avatar asked Apr 23 '14 23:04

wgpubs


People also ask

Where should VENV be placed?

The virtual environment tool creates a folder inside the project directory. By default, the folder is called venv , but you can give it a custom name too. It keeps Python and pip executable files inside the virtual environment folder.

Should you use VENV in production?

Yes, I think you should use virtualenv to deploy it into production. It makes things a lot easier and cleaner for you, especially if you plan on deploying multiple services, e.g. django based websites or other python projects.

Should I use VENV or virtualenv?

If you need the additional features that virtualenv provides over venv, then you obviously should use virtualenv. If you're satisfied with your current setup with venv, then there's no reason to choose virtualenv.


1 Answers

Here are my thoughts:

Arguments for grouping in a common folder

  • Cleaner management of multiple venvs on a given machine. Good tools to support checking which are available, adding new ones, purging old ones, etc.
  • More sensible (and more space-efficient) when sharing one or more venvs across more than one project
  • Allows the use of some nice features like autocompletion of venv names

Arguments for keeping with the project

  • Clear relationship between the venv and the project. Eliminates any ambiguity and less error-prone since there's little chance of running the wrong venv for a project (which is not always immediately evident).
  • Makes more sense when there is a one-to-one relationship between venvs and projects
  • May be the preferred approach when working in teams from separate accounts.
  • More straightforward when deploying across identical hosts; (just rsync the whole project). Nothing stopping you from doing this with a venv in a common folder, but it feels more natural to deploy a single tree.
  • Easier to sandbox the whole application.

I tend to prefer the former for more experimental / early-stage work, and the latter for projects that are deployed.

like image 99
StvnW Avatar answered Oct 18 '22 11:10

StvnW