Guia de estilo - Local de criação de ambientes virtuais python

Existem pelo menos duas decisões relevantes para gerenciamento de ambientes virtuais, localização e nome, gerando as seguintes alternativas:

localização centralizada (eg. ~/.virtualenvs) com nome por projeto (eg. my-project)
localização por projeto (eg. my-project/) com nome genérico (eg. venv/ ou .venv/)
localização por projeto (eg. my-project/) com nome por projeto (eg. my-project ou .my-project)

Links

venv docs

A common directory location for a virtual environment is .venv. This name keeps the directory typically hidden in your shell and thus out of the way while giving it a name that explains why the directory exists. It also prevents clashing with .env environment variable definition files that some tooling supports.

Naming Conventions for Virtual Environments

I create all my virtual environments in one directory and then set an environment variable with the path to that directory: export $VENV=/path/to/venvs. So, when I need to activate one, I use the command source $VENV/[project name]/bin/activate.

Introduction to Conda for (Data) Scientists

It is often a good idea to specify a path to a sub-directory of your project directory when creating an environment. Why?

Makes it easy to tell if your project utilizes an isolated environment by including the environment as a sub-directory. Makes your project more self-contained as everything including the required software is contained in a single project directory. An additional benefit of creating your project’s environment inside a sub-directory is that you can then use the same name for all your environments; if you keep all of your environments in your ~/miniconda3/env/ folder, you’ll have to give each of them a different name.

transparencia-mg / handbook

Guia de estilo - Local de criação de ambientes virtuais python #16

Links