[BerislavLopac]

I'm not sure how the location of the environment affects dependencies; the environment is isolated regardless of where it is located. Also, the virtualenv location doesn't have to be in the home directory; it can be anywhere your user has access to, the home is simply most convenient.

[MereInterest]

Using a common location means that unique names must be maintained across multiple projects, which is a recipe for disaster.

[BerislavLopac]

Most definitely in automated setups, i.e. in production. (I personally never depend on virtualenvs in production, preferring to have a fully isolated environment either via Docker or even better a dedicated VM.)

But in development, where you manually switch between environments, a centralised setup is great. You don't have to worry about gitignoring the virtualenv directory, or maintaining paths in general -- a common problem with virtualenv in your code directory is that IDEs and linters and similar tools tend to just cut through and parse everything, unless explicitly prevented. With virtualfish/virtualenvwrapper, the process is simply `workon {envname}` and you have everything in place.