How to Setup a Python Virtual Environment

We Are Not Pair!!! Unofficial Guide!!!

What is a Virtual Environment?

Python, 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,’ as is the case on Pair Networks servers. 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. Inside our project we can just spin up a new python virtual env and install those required modules.

Setting Up a Python Virtualenv

First make sure you have Python3 and Pip3 installed. If you’re working on a Pair server then they will already be installed.

Then use pip3 to install the virtualenv module.

pip3 install virtualenv

Next use the virtualenv command to initialize a new python virtual environment.

virtualenv venv

After that use the source command to active the new virtual environment.

source venv/bin/activate

Finally, you’re ready to install some modules locally.

pip3 install requests

And run some python code using your newly installed modules.

python3 -c "import requests; print(requests.get('https://www.pairsecrets.com/'))"

Once you’re all done installing modules and testing code you can exit the virtual env with deactivate.

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 within 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.

user@server:$FlaskApp> pipreqs app/
INFO: Successfully saved requirements file in app/requirements.txt
user@server:$FlaskApp> 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. For example,

(venv) user@server:$app> python3
Python 3.8.5 (default, Jan 1 1970, 00:00:00) 
>>> import os
>>> os.environ['VIRTUAL_ENV']
'/usr/home/username/public_html/site.com/FlaskApp/venv'
>>> quit()
(venv) user@server:$app> echo $VIRTUAL_ENV
/usr/home/username/public_html/site.com/FlaskApp/venv
(venv) user@server:$app> deactivate
user@server:$app> [[ -z  $VIRTUAL_ENV ]] && echo "...nada..."
...nada...