I stumbled upon this (fist entry in google) while I was looking for a proper naming convention. I feel I should comment.
I usually name my virtualenv .env. On unix-like systems they will be hidden and thus keep the project folder a little bit cleaner. I also feel that .env fits well with .idea, .git and .gitignore as project related tools but not actually project files. Adding all those dot-folders/files to .gitignore makes it clear that they all are project related tool.
However, I said I was looking for a proper naming convention. This is because having several related projects open at the same time makes it very hard to keep track which virtualenv is which (especially if projects have similar named files/folders). Thus, it may be beneficial to name the virtualenv like the project or an abbreviation thereof (with dot in my case). Apart from that there seems to not be a proper naming convention.
In case you are looking for a way to rename the prompt of your virtualenv differently from what you've named your virtualenv, you can edit .env/bin/activate:
PS1="(`basename \"$VIRTUAL_ENV\"`)$PS1"
While most of the above seems ok, .env is the only thing I would consider to be actually really wrong, as it clashes with deployment best practices.
According to the great book "Test Driven Development in Python" there is a convention forming for service deployment in general to put configuration data into a .env file in your projects root directory. Google also for "twelve factor app". In this context .env stands for the local "Environment" as in environment variables and you document that .env is not to be confused with a Python venv by omitting the 'v' at the start ;-)
This file typically gets referenced in the systemd unit file, e.g.
[Service] .... User=webapp WorkingDirectory=/home/webapp/sites/myproject.provider.com EnvironmentFile=/home/webapp/sites/myproject.provider.com/.env ExecStart=/home/webapp/sites/myproject.provider.com/virtualenv/bin/gunicorn \ --bind unix:/tmp/myproject.provider.com.socket \ myproject.wsgi:application
So while you technically can do so, using .env will be confusing for most everybody else.
Also I would advise against using hidden venv directories. It is exactly the point of virtual environments, that you have a sandbox with its own /bin /lib etc. which is the public binary interface to your app and should be directly called into by system integration, see above. Just like /usr/local/bin, /usr/local/lib. And you would not make /usr/.local hidden, just to have a "cleaner" directory tree, right?
The official Python documentation on Virtual Environments says:
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.envenvironment variable definition files that some tooling supports.
That's a pretty good starting point and endorsement.
With that said, it really comes down to personal preference. I'd prefer to keep that directory hidden as I rarely interact with it.
It also doesn't need to be in git repositories so it is a good candidate for .gitignore files.
What about including python version used? I'm using pyenv and when you create a virtual env "$ pyenv virtualenv 3.9 env_3.9" and you activate that in a local project "$ pyenv local env_3.9" it saves a file .python-version with "env_3.9" as content. I think i prefer this method as it tells others what version I'm using exactly for that project. I'm new to Python so guide me to a better approach if there is any convention way of doing it!
Remarkbox