Before I put names like: MyVirtualEnv, or put domain name myclientedomain.com.br.
But now I've tried find a simple conventions. So, I'm going to use like you right now, myvirtualevn.
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:
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.
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?
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.
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!
Comments
virtpyexport
some responses from IRC:
envlocalenvor naming the virtualenv after the project/application it supports.
export
I only recently started using virtualenv, but so far I have been creating a new one for each project or django site.
export
@doug, so you name them after your project?
export
Before I put names like: MyVirtualEnv, or put domain name myclientedomain.com.br. But now I've tried find a simple conventions. So, I'm going to use like you right now, myvirtualevn.
export
venvexport
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.envfits well with.idea,.gitand.gitignoreas project related tools but not actually project files. Adding all those dot-folders/files to.gitignoremakes 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:export
While most of the above seems ok,
.envis 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
.envfile in your projects root directory. Google also for "twelve factor app". In this context.envstands for the local "Environment" as in environment variables and you document that.envis not to be confused with a Pythonvenvby omitting the 'v' at the start ;-)This file typically gets referenced in the systemd unit file, e.g.
So while you technically can do so, using
.envwill be confusing for most everybody else.Also I would advise against using hidden
venvdirectories. 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/.localhidden, just to have a "cleaner" directory tree, right?export
The official Python documentation on Virtual Environments says:
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
.gitignorefiles.export
An update from me, I now use
envfor most of my projects.export
I named my virtualenv as 'sg_env' Is that correct?
export
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!
export