Compiling an older version of Python for virtualenv

04 Sep 2021

I don’t like it when a Python project requires a specific version of Python to run. Doubly so if said project is a school assignment.

(Click here to skip the whining and go straight to the actual guide.)

I mean, at least the professor was considerate enough to state it from the get-go:

Okay, fine. At first, I thought this assignment was meant to be completed using the school’s own distro. Maybe it ships with an older version of Python by default? I spin up the school distro VM and–

Welp.

Yeah, that’s not old enough.

Downgrading Python system-wide is obviously a nonstarter. That’s just asking for trouble. I’d have to compile an older version from source and use it via virtualenv. It’s not a big deal, but annoying and time consuming.

Searching for Answers

Last time I compiled Python from scratch was some years ago. I’ve forgotten everything on how to do it since.

There are plenty of guides online on how to set up a virtualenv using different versions of Python, but they usually involve how to set up a 2.x environment in a system that defaults to 3.x and vice versa. Not helpful. Other guides assume that you already have an older version of Python installed already. Well, I’m not on Windows. I can’t just go and download a one-click installer for an arbitrary version number.

In the end, I found this answer on Snack Overflow. Close enough.

Tangent: it’s on AUR already, you nonce!

Technically, I don’t need to do any of this. I’m on Arch and there’s a Python 3.7 package on AUR.

I’m not going to use that.

My issue with AUR in general is key management. I already have way too many packages from AUR and I really don’t feel like janitoring my keyring more than I have to. Besides, I only need to keep this release around for a semester. I don’t plan on touching this version ever again unless there’s a security update.

Compiling

Even though the assignment stipulates that 3.7 “should work” and doesn’t guarantee anything, I’m going with that version. Surely this won’t bite me in the ass down the road, right?

I downloaded the latest 3.7 release (3.7.11) from the official website and went to work:

$ tar -xf Python-3.7.11.tar.xz
$ cd Python-3.7.11
$ ./configure --enable-optimizations --prefix=/opt/python3.7.11 --exec-prefix=/opt/python3.7.11
$ make

At this point, I stepped away from my computer and let the thing compile. It took forever and I was not happy about it.

Tangent: does it have to go in /opt?

According to hier(7):

       /opt   This directory should contain add-on packages that contain
              static files.

Well, it’s technically not an add-on “package” but it’s not in Arch’s official repository either, as far as I can tell. I considered sticking the binary in ~/.local/bin but that just felt wrong. I prefer to keep that directory exclusively for whatever messy scripts I write.

So, /opt it is, I guess.

Installing

The Snack Overflow answer makes it clear that install should not be used here:

$ sudo make altinstall

Cool. Time to actually use the damned thing.

Time for virtualenv…

I went ahead and created an environment named python_37:

$ virtualenv $WORKON_HOME/python_37 -p /opt/python3.7.11/bin/python

Replace $WORKON_HOME with whatever directory you use for your virtualenvs. Mine points to ~/.local/share/virtualenvs.

Afterward, it’s just a matter of activating the environment:

$ source $WORKON_HOME/python_37/bin/activate
(python_37) $ python --version 
Python 3.7.11

Presto! It took about an hour to find the answer and compile the runtime. About ten minutes give or take for the project itself.

Thoughts

I understand that professors are busy people. They have papers to grade, answer questions, attend meetings, work on their own research, and so on. But how long does it really take for them to change a single statement in a file that students are prohibited from modifying?

×