Virtual Environments: Why Are They Useful?
As a self-taught programmer, I didn’t come across virtual environments until after I landed my first commercial role. When working on personal projects we may not revisit a previous project or work on a project for long enough that virtual environments are needed. If you are like me, this guide will hopefully help get you up to speed with the definition, uses and correctly setting them up.
Virtual environments act as a ring-fenced area within your computer for a specific project to run in, with its own distinct versions of packages installed. Over time, tools such as Python and its packages are updated or changed. Some functions for example, may be discontinued or its use amalgamated into another function.
Your system as a whole may have the latest and greatest versions of python (e.g. currently 3.9) running. However, when trying to run a project that was written in the past, you may find that it breaks. This is because of specific version dependencies that the project relies on (e.g. Python 2.4) but your PC interprets python code using version 3.9. Without Virtual Environments, we would have to uninstall Python 3.9 then install 2.4 and all dependencies required. This takes away valuable time from watching our favourite programmer-youtubers.
Virtual Environments to the rescue
To work around this issue, we have something called ‘Virtual Environments’.
an isolated Python environment where a project’s dependencies are installed in a different directory
Think of these environments as sort of Narnia for your computer. Within these environments, specific versions of Python and packages can be installed without affecting other installations outside of the environment. Irrelevant versions that exist outside of the environment do not interfere with our project whilst we are within the environment. For historic projects, these environments can be thought of a time machine, whisking the project back to the state that it was initially written for.
Best Practice
For code written in a commercial setting, virtual environments ensure that code does not break when Python is updated on the computer as a whole. Depending on the application of the code, this is crucial to prevent the business losing money due to system outages caused by reliance on that piece of code.
A nice by-product of virtual environments is that we can update versions of installation and install new packages without worrying about whether or not any projects on our system will break. Therefore as a rule of thumb, every project should use its own virtual environment that is created at the beginning of the project.
If you are planning on getting hired as a programmer at some point, I would recommend getting practice with creating and using virtual environments. In the next post, I will document the steps to create a virtual environment, as well as some mistakes I have made with their solutions.
