Possibly fictitious excerpt from the Python Conference announcement of Virtual Environments.
Most honorable Python developers, please raise your hand if you’ve ever gone from the highs of writing Python to the dreary comedowns of library version control.
“Everybody raises hands”
Raise your hand if you’ve ever been stuck all day trying to get version 1.4.2a of library A to work alongside 1.23 of library B in Python 2.7 for project one, all the while you need 1.5c of library A and who knows what for library B to get it to work for Python 3!!
“ People jump up and down, flailing their arms in agreement”
As expected, ladies and gentlemen, this version control malady of Python has afflicted us all at one stage or another. Some consider it the price the gods put on the usage of this holiest of languages.
“ The crowd agrees, discontent develops, the priestly python developer consults his holy PEP https://www.python.org/dev/peps/ to try soothe the crowd, ‘for purity this must be so!’”
I stand here today in defiance, I’m here to tell you that a group of apostatic engineers have given me the solution. In the goodness of my heart I’m gonna share it with you all today. Available for one conference only, at the low low price of free, do you good people desire it!? Are you prepared for revolution!?
“The crowd erupts in anticipation and agreement, people high fiving left and right, up high AND down low. A poor soul, who has been manualy managing library versions for 20 projects, faints in the corner of shock, never believing such a thing possible”
The answer ladies and gentlemen,… The answer is Virtual Environments.
As you can tell Virtual Environments are clearly a big deal in Python. As listed on the website.
“A Virtual Environment is a tool to keep the dependencies required by different projects in separate places, by creating virtual Python environments for them. It solves the “Project X depends on version 1.x but, Project Y needs 4.x” dilemma, and keeps your global site-packages directory clean and manageable.”
Ideally you have a main python3 installation, which has all up to date library versions, that is a catch all for simple test projects. Then for each separate project it’s recommended, that you use the VirtualEnv tool to create a virtual environment that has all the library versions you want to use. You can have different virtual envs with different python versions also.
Here’s a quick outline of how it’s done. You can install it via PIP (Comes with python):
$ pip install virtualenv
Then for your project
$ cd my_project_folder
$ virtualenv venv
This will create a folder in the current directory that contains all Python executable files, along with a copy of ‘pip’ you can use to install project specific libraries.
To use a specific version of python for your project use
$ virtualenv -p /usr/bin/python2.7 venv
This will create a python2.7 virtual environment
To activate your virtual environment, type
$ source /venv/bin/activate
Now anything you do in python will be as if this environment was your main one.
It’s that easy! It might not seem necessary when beginning a project but trust me. Once you start adding a lot of libraries, a problem is going to crop up eventually and you’ll wish you took these simple steps at the beginning.
Something to note, if you are using the Anaconda distribution of Python you can use their implementation of VirtualEnvironments. http://conda.pydata.org/docs/using/envs.html. I’ve been using this and it’s perfect for Scientific Python work. Also if you like automation, you might like this tool which automatically activates the virtual environment when you enter your projects folder, https://github.com/kennethreitz/autoenv. Also here’s an actual Python Conference talk about Virtual Environments, https://www.youtube.com/watch?v=Xdv7vwIIThY
I mean, people, Snake oil <—> Python, pun of a lifetime. Maybe I’ll do more of these Pythonic public service announcements. Drop me a comment if you have any questions or feedback!
( Image: Link Carol M. Highsmith [Public domain], via Wikimedia Commons)