Add "latest" aliases

[nicktimko]

A small usability proposal: add "latest" (release) aliases, so something like pyenv install ...

• 2, 2.x, 2-latest would install (as of now) 2.7.11, or
• 3.4, 3.4.x, 3.4-latest would install 3.4.4.

I'm semi-indifferent to what scheme to use, as long as it's short and simple. Currently there are X.Y releases in the list, but could move them to X.Y.0?

Also perhaps when asking for a "latest" version, force an update of the version list?

[lararosekelley]

An alternative in the meantime (only tested on Mac OS 10.11):

PYTHON2_VERSION="$(pyenv install -l | grep -e '2.[0-9].[0-9]' | grep -v - | tail -1)"
PYTHON3_VERSION="$(pyenv install -l | grep -e '3.[0-9].[0-9]' | grep -v - | tail -1)"

As of today, they return 2.7.11 and 3.5.1 respectively, the latest versions available for each major Python release.

[yyuu]

Basically I don't like to add such implicit feature in pyenv itself. I believe this can be implemented as a plugin with providing install hook.

I confirmed that installing this hook script at ~/.pyenv/pyenv.d/install/latest.bash worked on GNU/Linux at least.

DEFINITION_PREFIX="${DEFINITION%%@*}"                                                          
DEFINITION_TYPE="${DEFINITION_PREFIX%%-*}" # TODO: support non-CPython versions                
if [[ "${DEFINITION}" != "${DEFINITION_PREFIX}" ]]; then                                       
  DEFINITION_CANDIDATES=($(python-build --definitions | grep -F "${DEFINITION_PREFIX}" | grep "^${DEFINITION_TYPE}" | sed -e '/-dev$/d' -e '/-src$/d' | sort -t. -k1,1r -k 2,2nr -k 3,3nr || true))
  DEFINITION="${DEFINITION_CANDIDATES}"                                                        
  VERSION_NAME="${DEFINITION##*/}"
fi

With it, you can install the latest version like this.

$ pyenv install -v 3.5@latest

[yyuu]

Actually I'm not sure how much portable sort(1)'s version sorting is. I guess it doesn't work well with BSD toolchain.

http://stackoverflow.com/questions/4493205/unix-sort-of-version-numbers

[nicktimko]

A "...latest" suffix would be more explicit if that's palatable.

On Tue, May 17, 2016 at 7:53 PM, Yamashita, Yuu notifications@github.com
wrote:

Actually I'm not sure how much portable sort(1)'s version sorting is. I
guess it doesn't work well with BSD toolchain.

http://stackoverflow.com/questions/4493205/unix-sort-of-version-numbers

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#602 (comment)

[yyuu]

@nicktimko I couldn't get what you meant. Could you show me some examples?

[nicktimko]

• 3-latest, 3.5-latest install candidates are identical to (as of now) 3.5.1
• 2-latest, 2.7-latest identical to 2.7.11
• 2.6-latest identical to 2.6.9
• 3.4-latest identical to 3.4.4

Effectively something like duplicating the files in plugins/python-build/share/python-build

[yyuu]

As of writing this, there're some versions which have -latest as their version suffix.

https://github.com/yyuu/pyenv/blob/master/plugins/python-build/share/python-build/miniconda-latest
https://github.com/yyuu/pyenv/blob/master/plugins/python-build/share/python-build/miniconda2-latest
https://github.com/yyuu/pyenv/blob/master/plugins/python-build/share/python-build/miniconda3-latest
https://github.com/yyuu/pyenv/blob/master/plugins/python-build/share/python-build/pypy-c-jit-latest
https://github.com/yyuu/pyenv/blob/master/plugins/python-build/share/python-build/pypy-c-nojit-latest

How do you think how the feature should behave for those versions? For example, should pyenv install miniconda3-latest install miniconda3-latest, or miniconda3-4.0.5?

Introducing special keyword like miniconda3@latest isn't so nice. But it'll work well with this kind of situation (as long as there's no version with @ in its version string). This could be kind of corner case, though.

[yyuu]

I'm not good at wording.... But I feel that the version specification like 3.5-latest (or, 3.5@latest) isn't explicit. Or, in other words, it's not deterministic.

Basically I don't like to add this feature as long as I can implement it as a plugin. I may create a new plugin based on the hook script I posted before, but will not bundle it to pyenv.

[lararosekelley]

@yyuu i think that even though latest is a non-deterministic version indicator, it's a very practical feature to add and something you see in many package managers out there (npm, etc). Understand the decision not to add it, but at the same time it doesn't hurt anyone if you do, and only benefits those that want to always install the latest versions of Python 2 and 3

[nicktimko]

pip install Django, docker pull python:latest, ...pull python:3 or ...python:3.5 are in the same boat.

Regarding those that already have a -latest suffix, they're functionally identical, though the "disambiguation" is pushed from the pyenv repo to Continuum Analytics' server.

fish> date
Tue May 31 15:01:35 CDT 2016
fish> diff -s (curl -s https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86.sh | psub) \
              (curl -s https://repo.continuum.io/miniconda/Miniconda3-4.0.5-Linux-x86.sh | psub)
Files /tmp/.psub.B8raWP3XDG and /tmp/.psub.7hCzGTVMLN are identical

CPython doesn't seem to do that same sort of mirroring from among their download bin, so doing that on the pyenv level would be cool. A hook looks like it might be clean-ish (woe to my bash-fu), but it also seems generally useful which is why I'm partially nudging for general inclusion ;).

[ssbarnea]

Any updates on this? I would really love to be able to install 3.5-latest and considering that we already have -dev suffix, it does make sense to use -latest.

[ssbarnea]

Any update on this? Let me explain why using bash scripts for detecting the values to use for latests/stable does not work: we need to put these values inside files like: circleci.yml, .travis.yml, Jenkinsfile, tox.ini and so on. It is almost impossible to do this in a way that would work with these systems.

If we would have these aliases the life of any pyenv user would be much better because we would not have to maintain these files and update them whenever each minor version of python is updated. We would have to update them only when we decide to drop or add support for a major version, like dropping 2.6, or adding 3.6, 3.6.

I don't care if we named it -latest, -stable or -current as long we can start using it right away.

[yyuu]

Anyone can implement the feature as pyenv plugin. Please don't try solving everything in one place.