First Experiences with Python Virtual Environments

**Virtual Environment – “A virtual environment is a Python environment such that the Python interpreter, libraries and scripts installed into it are isolated from those installed in other virtual environments, and (by default) any libraries installed in a “system” Python, i.e., one which is installed as part of your operating system.”** -python.org

Getting Going

As a Python project quickly begins to develop, we found that using python’s virtual environments might be a useful feature to implement. Not as nature-y as it may sound or that the above picture suggests…

Being a bit of a Python newbie myself, I needed to do a bit of research about what exactly a Python virtual environment is and how it can be useful for our project.

I began with the tutorial at: https://docs.python.org/3/tutorial/venv.html

The tutorial helps you set up your first environment, but does not really give you an idea of the capabilities behind the virtual environments or why you would want to use them. So I set out to find some examples and programs of my own that could provide me the knowledge I was looking for.

Why are virtual environments useful?

At first look, it would seem that the virtual environments could be useful in a variety of ways, but the initial usefulness was found in the requirements used. With so many different libraries and requirements, conflicts may arise between python projects. This issue is solved efficiently and effectively with the virtual environments. As a carpenter and a scientist use vastly different tools for the trade, you may have a couple python scripts or programs that use different tools or even just different versions of the tools. You can set up your python work spaces (i.e. your virtual environments) to equip your workers with the tools they need without having a mess of irrelevant ones to clutter the work space just as you would set up a wood shop and a lab.

Another issue is that some projects use the same tool, but different versions of that tool. Even as someone who’s only worked on a couple of python projects, I’ve already had this issue. It gets rather annoying if you have to reinstall a tool again and again to match versions if you have to work on two projects at the same time. Virtual environments are an easy way to get around this problem and make things overall easier for anyone else who is trying to continue with the project.

How do virtual environments work?

The magic happens by containing all of the project’s requirements and pip installations within this virtual environment. So, if you have a python project that uses a 3rd party library, you can install it into your virtual environment and next time you run your project through the environment, it will be there (and only there)! In this example, we’ll use skyfield.

Here’s how it works:

1. I’ve started off with a mars.py, a slick little program I found that prints out Mars’ position in the sky.
2. I’ve created my virtual environment using the steps up to 12.2 from the tutorial I mentioned above (here for easy access)Note: I am doing this on MacOS. If you are using a different OS, the python tutorial will have the steps you need!

You can see here that after activating the python environment, I have a (blog-env) tag before my commands. That’s how you know you are working inside your virtual environment!

3. To show you some of this magic I’ve been talking about.. I deactivated my environment so that I am no longer in it, and am going to run my mars.py script. This throws some errors as I don’t have the correct requirements outside of my blog-env.

mars.py can’t find the libraries it needs because they are only inside the virtual environment.

4. Now that I’m inside my blog-env environment, I will install skyfield using:

pip3 install skyfield

5. Now that I have the requirements that I need, the program runs and tells me where Mars is!

Just like that, you can find where Mars is in the sky!

Wrapping Up

While using only one script, python environment’s benefits don’t shine as they should. Once you begin having different scripts and projects, these benefits do become apparent. Taking advantage of a requirements.txt file, you can also add a little more benefit. A requirements.txt file lists the libraries and the versions that are currently being used in a current environment. That way, developers will all have matching libraries when working on the same project. It also will only take one command to install them all as well!

Having this knowledge will help you take one step closer to being the python pro you know you can be….or so I’m told. And if you have questions about an embedded project you’re working on, Dojo Five can help you with all aspects of your devops for embedded journey! We are always happy to hear about cool projects or interesting problems to solve, so don’t hesitate to reach out and chat with us on LinkedIn or through   email!