Install latest python version with pyenv

Question

With ruby-install, to install the latest stable ruby version, one needs only ruby-install ruby.

However, with pyenv one seems to need to do something ridiculous like pyenv install "$(pyenv install --list | tr -d ' ' | grep --extended-regexp '^[0-9.]+$' | tail -1)".

Is there a better way to do this? Why do python tools seem to always make installing the latest version such an obtuse process compared to ruby (gem update vs pip list --outdated | awk '!/Could not|ignored/ { print $1 }' | xargs pip install --upgrade)? I hope I’m the one missing something, but I can never find easy solutions for this online.

Answer 1

Combining this with this answer, another option is:

pyenv install --list | grep --extended-regexp "^\s*[0-9][0-9.]*[0-9]\s*$" | tail -1 | tr -d ' '

The regex looks for lines that start with a number ^[0-9], followed by any amount of dots and/or numbers [0-9.]*, and end with a number [0-9]$. Leading ^\s* or trailing \s*$ whitespaces may occur but don't have to.

Edit: to install:

pyenv install $(pyenv install --list | grep --extended-regexp "^\s*[0-9][0-9.]*[0-9]\s*$" | tail -1 | tr -d ' ')

Answer 2

The following is a little shorter than your suggested "hack" and assumes you don't want versions like 3.130a2 and 3.5.0b1.

pyenv install $(pyenv install --list | grep -v - | grep -v a | grep -v b | tail -1 | tr -d ' ')

Answer 3

Since pyenv 2.3.6 (November 2022) it will automatically resolve a prefix version to the latest revision:

pyenv install 3.10

Note that, as the link indicates, pyenv uninstall does not do prefix resolution, it needs the full version upfront.

You may need to update your pyenv if it's too old (pyenv -v will tell you the version of pyenv itself)

---

old outdated answer:

FWIW as of version 1.2.24 (March 2021) this issue is finally fixed:

pyenv install 3.10:latest

pyenv/pyenv#1831 lets you suffix any section of version with :latest (just avoid :latest alone it yields weird results) to get the latest revision for that section e.g. right now 3:latest will install 3.11 alpha, 3.10:latest will install 3.10.0.

It's not quite perfect when dealing with non-mainline, and :latest doesn't work in every context, but it's progress.

Answer 4

Try https://github.com/momo-lab/pyenv-install-latest

Installation...

git clone https://github.com/momo-lab/pyenv-install-latest.git "$(pyenv root)"/plugins/pyenv-install-latest

Latest 2.7 build of python...

pyenv install-latest 2.7

and for python 3...

pyenv install-latest

Answer 5

Because being on the latest "stable" version of everything is rarely a good idea. Different upstream maintainers have a different concept of stable (my little pymumble fork and eglibc have very different notions of release quality). The newest stable version often introduces breaking changes and it is often inadvisable to upgrade blindly without understanding what changes you're bringing into your codebase.

In ruby's case, 1.8's threads were greenthreads and 1.9's threads were kernel threads. While they maintained the same API, completely changing the underlying threading module when your language supports C gems is not acceptable in any universe known to me. Upgrading any multi-threaded code to the latest stable ruby was highly likely to break everything. Arch Linux had a similar fiasco when it upgraded everyone to python 3, ignoring the myriad dependencies it their own repos against python 2.

The usual solution is to depend on your distro's repo for new version of python and use python's virtualenv or python3's venv to create environments based on that specific version of python.