Ceci est une ancienne révision du document !
Virtually Python
Greetings again fellow Sentient Lifeforms. Things here at landing pad 2997 on Terra still haven’t calmed down yet. Hopefully, by the end of the month, I’ll see things starting to calm down as we begin to transition to Autumn.
I have to make an apology to all of you. A few months back (FCM 204 and 205), I was discussing Sphinx and how to use it. When I explained the process of installing Sphinx, I showed how to create a virtual environment and how to activate, but I failed all of you by leaving it at that. Not only did I not show how to deactivate it, I failed to show how to reactivate it. I also failed all of you by not going deeper into virtual environments in general. In fact, I’ve never really discussed Virtual Environments before. I intend to fix those points now. We’ll be discussing all things Virtual this month.
What is a Virtual environment?
According to the Python official documentation, a Virtual environment is “a self-contained directory tree that contains a Python installation for a particular version of Python, plus a number of additional packages.”
Basically, when you use a Virtual environment, you create a special ‘version’ of Python that has no packages installed except pip and setuptools. Any packages you install, usually via pip, will only be available in the Virtual environment, not your normal Python installation. This can actually be a good thing. From the Python.org documentation site, you can see the main reason for wanting to do this…
“This means it may not be possible for one Python installation to meet the requirements of every application. If application A needs version 1.0 of a particular module, but application B needs version 2.0, then the requirements are in conflict and installing either version 1.0 or 2.0 will leave one application unable to run.”
I’ll be perfectly honest with you. I’m the world's WORST when it comes to just throwing a new library into my Python’s installation without using a virtual environment. And I’ll even admit that I’ve been bitten by the conflicts that put me behind the “8 ball” more times than I would be willing to admit. I’m trying to be better, really I am.
Do you REALLY need to use a Virtual environment?
Strictly speaking, no, you don’t NEED to use a Virtual environment. If you never intend to use any third-party libraries, and the basic Python “built in” libraries are all you will ever need, then you don’t need to worry about Virtual environments.
However, in the real world, you will eventually need some package that needs to be ‘installed’ via pip. Every time you install a third party package, you run the risk of having a version conflict.
So you can take the risk and just keep adding libraries to pip, or you can start using virtual environments. Just don’t say that I didn’t warn you.
Dealing with a Virtual environment
So, how do we get started with Virtual environments? You have to create the virtual environment folder before you can use it, and then you need to activate it.
Create the Virtual environment
The syntax to create a Virtual environment is pretty simple…
Python -m venv {path/to/new/virtual/environment}
Normally, you will want to create the folder to hold the virtual environment named either venv or .venv in the project folder. You can also create a container directory that will hold many virtual environments like ~/.virtualenvs. When I get around to remembering to use a virtual environment, I always create the folder within my project folder as .venv. Having that hidden folder there reminds me that I’ve got to activate it before I can work on the project.
Assuming you want to create the Virtual environment in your project folder (which I suggest is the best way to do things), then, in a terminal window from your project folder, type…
$ python -m venv .venv
Once you’ve created the environment, you need to activate it:
$ source .venv/bin/activate
You should see your terminal prompt change to remind you that you are using a virtual environment.
(venv) greg@Earth2:~/Desktop/MyProject/test$
As long as you are using the terminal to create commands, you will be using the virtual environments. However, if you do something outside of that terminal, you are using the default Python instance for your system and will not properly handle your project.
When you are done, use the deactivate command to release the virtual environment.
Just type…
deactivate
in the terminal and go on your merry way.
It’s always a good idea to deactivate the virtual environment before you close the terminal window. It should never break anything, but it’s better to tidy up behind yourself.
Using Virtual environments with Pyenv
If you are using pyenv to handle your Python versions, you can simply use the instructions above, but pyenv does have a special way to handle virtual environments directly.
When you installed pyenv, it should have installed the virtualenv addon. The syntax would be
pyenv virtualenv {python version} {project name}
So let’s say that you have installed the following versions of Python into your pyenv… 3.8.10, 3.9.10, 3.10.10, 3.10.12, 3.11.4, 3.11.7, 3.12.0, 3.12.2
Further, let’s say that you want to use 3.11.7 for this project and you want to name the virtual environment “project1” . Your terminal command line would be…
pyenv virtualenv 3.11.7 project1
Once you get the command-line prompt back, activate it by typing
pyenv activate project1
Your command line prompt will now change to
(project1) greg@Earth2:~/Desktop/MyProject/test$
However, unlike using straight Python, what doesn’t happen is you don’t get a dedicated folder for the environment in your project folder. In actuality, this can be better or worse, since you don’t have the folder to remind you that there is an environment already there for you (or anyone else who needs to know).
To deactivate the pyenv version of the environment, simply do a ‘pyenv deactivate’.
(project1) greg@Earth2:~/Desktop/MyProject/test$ pyenv deactivate
Remember that when you create the pyenv virtual environment, you need to remember that the version you tell it is one that you already have added to your pyenv library of versions. Otherwise, you will get an error. I like to keep a list somewhere that I can look at of all the python versions. It just keeps me going in the correct direction.
Well, that’s about it for this time. Until next time, as always; stay safe, healthy, positive and creative!