More actions
What is a Virtual Environment?
Python, just like any programming language, has modules (aka, extensions, imports, includes, libraries, dependencies). These modules are just pre-written pieces of code, like functions and objects, that you can import into your project and use to extend the functionality and ease of use of the base language. Normally on your own computer you'd install modules globally at a system-wide level. The problem with depending on globally installed modules is that it makes code less portable. For example, if script.py is moved from 'system A' to 'system B', then the person doing the move must install both script.py and any dependent modules on 'system B.' This can be a problem if you don't have administrative access to 'system B.' Likewise, globally installed modules can cause problems if two pieces of software depend on different versions of the same module.
To help remedy these issues, Python has Virtual Environments. Virtual Environments are used to install all of your Python modules inside of a local folder that often lives inside of your project directory and is specific to it. Now, if script.py depends on moduleName and 'system B' lacks or has a different globally installed version of moduleName, then its no big deal. Along side our project we can just spin up a new python virtual env and install those required modules using a requirements.txt file.
Setting Up a Python Virtualenv
1) Initialize a new virtual environment:
python3 -m venv venv
That will create a directory called venv, where your locally installed modules will live.
2) Activate your virtual env:
source venv/bin/activate
That will drop you into a modified shell. Now, any modules installed using pip will automatically be installed into the venv dir.
3) Install a module locally:
pip3 install requests
4) Run some python code with your newly installed module:
python3 -c "import requests; print(requests.get('https://johnlradford.io/'))"
5) Exit your virtual env when you're done installing modules and testing your code:
deactivate
Extras:
* Requirements.txt
It is customary to include a requirements.txt file in your project directory for use in listing out the modules needed to re-assemble your project. Normally you'd use pip freeze to generate a requirements.txt file. But that doesn't seem to work with python virtual envs. So instead I've used pipreqs to get a requirements.txt file. You can install pipreqs with pip3 and then just point the tool at a dir containing a python script. It will look at the import lines from the scripts in that dir and print out a list of the required modules.
blue@server:$app> pipreqs app/ INFO: Successfully saved requirements file in app/requirements.txt blue@server:$app> cat app/requirements.txt Flask==2.0.1 requests==2.22.0 beautifulsoup4==4.9.3
* Venv Persistence / Python Sub Shells
Note, if you're testing an app you will need to be inside of the virtual env to have access to the modules the app needs. From my testing, it seems the virtual environment will remain set if you drop down into a python shell and pop back up. Likewise, it seems to remain set if you run python with the -c option like used in the example above. This all seems to be maintained via the VIRTUAL_ENV shell environment variable (idk just sorta spit balling there). For example,
(venv) blue@server:$app> python3 Python 3.8.5 (default, Jan 27 2021, 15:41:15) >>> import os >>> os.environ['VIRTUAL_ENV'] '/var/www/html/FlaskApp/venv' >>> quit() (venv) blue@server:$app> echo $VIRTUAL_ENV /var/www/html/FlaskApp/venv (venv) blue@server:$app> deactivate blue@server:$app> [[ -z $VIRTUAL_ENV ]] && echo "...nada..." ...nada...