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 | sed 's/^ //' | grep '^\\d' | grep --invert-match 'dev\\|a\\|b' | 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

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 2

以下内容比您建议的“hack”短一点，并假设您不想要3.5.0b1版本。

pyenv install $(pyenv install --list | grep -v - | grep -vb | tail -1)

Answer 3

FWIW as of 2021 this issue is finally fixed (better late than never): 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 eg 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

Combining this with this answer, another option is:

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

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)

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.