pyenv provides an easy way to install almost any version of python from a large list of distributions. I have simply been using the version of python from the os package manager for awhile, but recently I bumped my home system to Ubuntu 21.10 impish, and it is only 3.9+ while the libraries I needed were only compatable with up to 3.8.
I needed to install an older version of python on ubuntu
I've been wanting to check out pyenv for awhile now, but without a burning need to do so.
installing
Based on the Readme it looked like I needed to install using homebrew,so this is what I did, but I later realized that there is a pyenv-installer repo that may have saved me this need.
https://waylonwalker.com/til/installing-homebrew-linux/
List out install candidates
You can list all of the available versions to install with
pyenv install --list. It does reccomend updating pyenv if you suspect that it is missing one. At the time of writing this comes out to 532 different versions!
pyenv install --list
Let's install the latest 3.8 patch
Installing a version is as easy as pyenv install 3.8.12. This will install it, but not make it active anywhere.
pyenv install 3.8.12
let's use python 3.8.12 while in this directory
Running pyenv local will set the version of python that we wish to use while in this directory and any directory underneath of it while using the pyenv command.
pyenv local python3.8.12
.python-version file
This creates a .python-version files in the directory I ran it in, that contains simply the version number.
3.8.12
using with pipx
I immediately ran into the same issue I was having before when trying to run pipx, as pipx was running my system python. I had to install pipx in the python3.8 environment to get it to use it.
pyenv exec pip install pipx
pyenv exec pipx run kedro new
python is still the system python
When I open a terminal and call python its still my system python that I installed and set with update-alternatives. I am not sure if this is expected or based on how I had installed the system python previously, but it's what happened on my system.
update-alternatives --query python
Name: python
Link: /home/walkers/.local/bin/python
Status: auto
Best: /usr/bin/python3
Value: /usr/bin/python3
making a virtual environment
To make a virtual environment, I simply ran pyenv exec python in place of where I would normally run python and it worked for me. There is a whole package to get pyenv and venv to play nicely together, so I suspect that there is more to it, but this worked well for me and I was happy.
pyenv exec python -m venv .venv --prompt $(basename $PWD)
Now when my virtual environment is active it points to the python in that virtual environment, and is the version of python that was used to create the environment.
Links
https://github.com/pyenv/pyenv#installation
I wrote this during my first few minutes of using pyenv. It's been working great for me since then and has been practically invisible. If you have more experience with pyenv I would really appreciate a comment on your experience below.
Top comments (3)
In order to have
pythonuse the current global pyenv version, you need to modify yourPATHenvironment variable. See #2 under "Basic Github Checkout". Here's what it says to do the ZSH:You could of course put that in the .zshrc instead of profile.
You need to make sure that the pyenv shims appear before the /usr/bin directory in the path. I'm not sure how the update-alternatives works with this, but I've never had an issue with pyenv with the shims at the front of the path. A call to
should point to the pyenv shim, given you restarted the shell
I put pyenv root right to the front of the $PATH and it was still going for system first. I ended up running update-alternatives --remove, and now pyenv has full control.
This works well with apt installed versions of python, but when you bump to 21.10, unless you add the deadsnakes ppa you can't get older versions. I don't understand it yet, but this doesn't work with pyenv. I wish it did though. It's likely because they maintain a bunch of distros of python and python3.9 could mean different things if you have pypy, anaconda, and core installed. I have no idea why they didn't go this route for sure.