Python environments are tricky, but they don’t need to be so tricky. Here is all the setup you need for many projects.
python3 -m venv .venv
source .venv/bin/activate
This will create a virtual environment called .venv
(I say “vee-env”) in the directory in which it is run.
It is a good idea to localize environments to projects, but you should not commit the venv folder to git (it will grow large).
Unfortunately, even with a venv, python dependency management is still a bit cumbersome.
You can keep dependencies in a requirements.txt
file, but doing so requires that you curate that file.
If you need something to be reproducible quickly, simply dumping it with
pip freeze > requirements.txt
works, but will give you an unnecessarily large list. Much better is to manually list what you install by adding it with version number to a requirements file, so that your file looks something like this:
pandas==1.1.2
numpy==1.19.2
matplotlib==3.3.2
If you do use venvs as suggested above, I strongly recommend including something like this little snippet of Ines Montani’s in your .bashrc
/ .zshrc
/ .shell-of-your-choice-rc
:
function venv {
if [ ! -d ".venv" ]; then
python3 -m venv .venv
echo -e "[38;5;2m✔ Created virtualenv .env[0m"
fi
source .venv/bin/activate
export PYTHONPATH=`pwd`
echo -e "[38;5;2m✔ Activated virtualenv .env[0m"
}
alias venv="venv"
With that snippet, you can create (if none exists) or activate (if one already exists) a venv in whatever directory you are in with just the venv
command.