Brief: This guide shows you how to set up Python environment on Linux and other Unix-like systems.
If you’ve ever tried to set up a Python development environment in Windows, you know how challenging it can be. Recently, Python released a new version of their installers that have made that process nearly painless, but that doesn’t mean you get the best development environment out of the box, so, in the spirit of a recent post on It’s FOSS about setting up a C++ environment, here’s how to do the same for Python.
Great news, Python’s already there
As a *nix user (because this applies to OsX as well) you already have some version of Python installed on your system. In fact, it’s probably a large part of how your package installer works. The real issue is finding out which Python version you have installed by default, and which Python version you are planning on programming with. So open a terminal and check what you have:
will return either Python3.x.x or Python 2.x.x.
Depending on what you get back, I’d also suggest trying the other release as well, by appending that number to the python command. In my case, the default Python install is 2, so I type:
and get back the appropriate Python 3.x.x response.
This will be important because it will determine how we run our Python code from whatever interpreter we end up using. There’s a whole different article to be written about changing your default Python install, so I’m going to avoid that discussion here. Just remember which one your machine defaults to, and which one you are wanting to target.
If you are missing one or the other, or if you find you are running an older version, just install the newest:
sudo apt-get install python *or* python#
One of the great things about Python is that it is fantastically simple to get working; this simplicity is also one of the pitfalls. Setting up a proper environment for working is going to be important, and can be confusing at first, because you might think you are ready to write with it simply installed on your machine.
You have to remember that for any version of Python, you are going to need to deploy that same setup to your production environment. Any of the packages you get from the package index, for example, will need to be installed on your production machine as well. It’s a good idea to keep track of these in a text file that can be used by pip to install them later.
The first thing to do is set up a virtual environment.
In Python 2 you’ll want to install virtualenv using pip:
pip install virtualenv
if you get an error here, saying that you need to install pip first, go ahead and do so. Pip’s the most reliable way to manage packages, and like the link above says, it’s the recommended way to do it also. (hint for OS X users that got here, try
sudo easy_install pip, you might have to use the command as pip2 instead of pip, just check for the –version)
With virtualenv installed, you can just
cd to your project directory, and then make a new environment:
this makes a bin of python files inside the current directory called my_project. That’s it, jump down to “Using your virtual environment” to see what to do next.
In Python 3, the virtual environment module may need to be installed.
sudo apt-get install python3-venv
Once you have it, just
cd into your project directory and run this command:
this makes a bin of python files inside the current directory called my_project.
Using your Python virtual environment
With your environment installed, the procedure is pretty much the same in both versions of Python. I’ve included the working directory in the following commands for clarity.
@path/to/my_dir$ source my_project/bin/activate
Basically, what this command is doing is using that local, clean install of Python in your virtual environment to run your commands. To test this, you could run your python interpreter from inside the environment and try to import a module (numpy for example) you know you have on your main install of python.
To get back out of the environment:
(my_project) me@path/to/my_dir$ deactivate
Whenever you are in your project as source, remember that you are going to be changing that source environment, but not your main environment, so anything you do to that Python is limited to that environment.
Making your Python environment worthwhile
While you are working, you’ll occasionally want to export a list of the environment packages, to be able to install the same environment packages on your production machine.
(my_project) me@my_dir$ pip freeze > requirements.txt
Doing this will create a text file inside your project directory which will act as a list of all the Python packages you have installed in that environment. This way, when you put your project on your production machine, you simply have to run:
pip install -r requirements.txt
Run Python programs in Linux
Now that we’ve got the development environment setup properly, we can test it by writing some simple python code. I use vim to write code, so that’s where you’ll see me start this next bit of Python3 code, then run it. Keep in mind that django isn’t installed on my main machine, just on the source.
So basically, you just need to use the command in below fashion to run a Python program in Linux:
Sorry, I had to change environments for this last gif, but you get the picture. Note that I’m in (my_project) as source when I run this the first time, and then I get the failure when I’m out of (my_project) as source.
There are a bundle of IDEs out there, and most of them handle this kind of thing well, if you pay attention to what you are doing. Just remember that the install of python inside of your project is the one you want to use to run your code.
Since I made the mistake, at a younger age of doing *nix stuff, I’m going to impart some wisdom here. Do not run any of the pip commands as
sudo. You’ll mess up your main install of Python, and that will mess up your Linux package manager… and basically, it will ruin your day. I lost a whole Mint install to this once, so just remember not to
sudo this stuff.
If you are interested, you should also learn to use pip on Ubuntu.