Create alias for MAJOR and MAJOR.MINOR python install versions

[heliocastro]

Too many issues will kill our team's development velocity, drastically.
Make sure you have checked all steps below.

Prerequisite

• Make sure your problem is not listed in the common build problems.
• Make sure no duplicated issue has already been reported in the pyenv issues. You should look for closed issues, too.
• Make sure you are not asking us to help solving your specific issue.
  • GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like Gitter, StackOverflow, etc.
• Make sure your problem is not derived from packaging (e.g. Homebrew).
  • Please refer to the package documentation for the installation issues, etc.
• Make sure your problem is not derived from plugins.
  • This repository is maintaining pyenv and the default python-build plugin only. Please refrain from reporting issues of other plugins here.

Description

• Platform information (e.g. Ubuntu Linux 16.04): all
• OS architecture (e.g. amd64): all

Current install list has no alias for latest each version.
So a proposed alias for latest stable <major> and <major>.<minor> would be an well accepted solution.
Using -dev would not be an option due the lack of stability

How this could work:

• If we ask pyenv to install python version 3 as of today of this issue it will install 3.10.5 as this will be the alias
• If we ask pyenv to install latest python version 3.6, it will install 3.6.15
• if we ask pyenv to install python version 2.5 it will alias to install 2.5.6

This is an small enhancement that will simplify installation when we don't need to care with **<patchlevel>**version, but only with <major> and <minor>

[native-api]

This has been requested for a long time this way or another.

We have plans to implement this (and use the donated money for its development, for the first time).
The current stumling block is which way to choose:

• Redirect explicitly, creating an alias
  • Then we'll need to maintain this alias -- i.e. decide when to change it, potentially in cases that users will find inappropriate.
  • Users might meddle with this alias themselves, making it impossible to decide reliably if it can be touched.
• Redirect implicitly, substituting the version passed by the user transparently
  • This is currently done for pyenv install x.y:latest
  • This will make changes "automagic" but will break assumptions like the fact that the version equals to the directory entry name
  • This will also fuse naturally with pyenv install vs pyenv global/local/shell -- in the first case, the latest known version needs to be chosen, in the second -- the latest installed.

So given the pros and cons, I'm currently gravitating to the 2nd implementation.

[native-api]

I was going to scout what other language managers do before making a final decision -- didn't allocate time for that yet.

[heliocastro]

Let me help on that, because my current job made me pass to mostly all env-like tooling. Let me present state of Node, Go, Rust, PHP and Ruby ( i linked the installer page directions )

• nvm - NodeJS env
  • Nvm do similar as pyenv, with a minor exception, it has a --lts flag for the ones that want to use latest LTS from Node. But we don't have that on Python.
    Example:

[root@fedora_docker /]# nvm ls-remote
v0.1.14
v0.1.15
...
v8.16.2   (LTS: Carbon)
v8.17.0   (Latest LTS: Carbon)
...

• rvm - Ruby Version Manager
  • This is a weird one, ruby in special have som many crazy variants for Rails, etc.. that create a starnge list of packages.
    rvm do hava the MAJOR MINOR idea above and one for the head devel version, though.
    They even have a specific process for forks ( too much for my point of view )
    Example:

[root@fedora_docker /]# rvm list known
# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.7[-head] # security released on head
[ruby-]1.9.1[-p431]
...
[ruby-]2.6[.6]
[ruby-]2.7[.2]
[ruby-]3[.0.0]
ruby-head
...
# JRuby
jruby-1.6[.8]
jruby-1.7[.27]
...

• rbenv - Another ruby weird one
  rbenv from the usage/layout point of view is really similar of pyenv, and versioning for install is pretty much same, with one exception, it includes even the pre-releases branch. Again, too much for my point of view.
  BUT this is a really difficult to install for a non tech savvy guy, and your best luck is if you have a package for your system or homebrew. It deals with compile the command line in C, and an extra step to install the install command ( I could start a rant about how developers don't know properly the tools they are using )

  Example:

[root@fedora_docker ~]# rbenv install -L
1.8.5-p52
1.8.5-p113
1.8.5-p114
1.8.5-p115
1.8.5-p231
1.8.6
...
3.0.4
3.1.0-dev
3.1.0-preview1
3.1.0
3.1.1
3.1.2
3.2.0-dev
3.2.0-preview1
...

• rustup - Rust installer
  Rustup itself is a Rust Swiss knife, not do only install related parts. But do not provide a list of possible targets/versions, so rust developers will install based on their reference knowledge or nightly.
  We hardly can compare with standard switch env tools, so i would not consider a good example.

• phpenv - PHP Version manager
  PHP env is the most similar to pyenv, functionality is straight out of the box. Do not have major/minor switchs, only straight versions.
  Example:

[root@fedora_docker ~]# phpenv install -l
Available versions:
5.2.17
5.3.2
5.3.3
...
8.1.7
8.1.8
8.1snapshot
8.2snapshot
...

• go - Manager for versions embedded on main tool
  Go has his installer embedded on language, based on git under the hood, but no list of versions. This is up to the developer

• gbm - Independent Go version manager
  This is kind of old, last change 2 years ago, and i don't know how become pointless or not after thew one above.
  It do have some kind of MAJOR MINOR possibility as well and a release one,
  Example:

[root@fedora_docker ~]# gvm listall

gvm gos (available)

go1
go1.0.1
go1.0.2
go1.0.3
go1.1
...
go1.18
go1.18beta1
go1.18beta2
go1.18rc1
go1.18.1
go1.18.2
go1.18.3
go1.18.4
go1.19beta1
go1.19rc1
go1.19rc2
release.r56
release.r57
...

[heliocastro]

So given the pros and cons, I'm currently gravitating to the 2nd implementation.
I agree, that would be more suitable.
let me know if i can help on coding or testing, as long you have a possible fixed idea.

[native-api]

I'm not sure what you can help with... so I'll let you decide.

The plan is to make it the same way as x.y:latest is implemented, but in version selection logic. And adjust the :latest logic to also understand x.y.

There's probably going to be a significant overlap in version comparison logic. We'll probably need to split off the common part into a library (rvm can show how these can be organized) or (probably preferrable) a separate internal subcommand.

[gwerbin]

When considering other "version managers", it might also be worth looking at:

• ASDF-VM (which has a Python plugin): I think this only supports exact versions.
• Choosenim: Supports a general "latest" and "stable" target (which they call a "channel"), I don't think offers much specificity beyond that.
• GHCup: Offers a lot of control, including "latest", "recommended", and both major and major.minor as aliases for major.<latest>.<latest>.
• OPAM: Somewhat idiosyncratic compared to the others. Supports lots of detailed "variants", but doesn't (as far as I know) support something like major.minor:latest.

There is also Plenv which I think is mostly a clone of Rbenv/Pyenv.

[native-api]

Implemented auto-resolving micro versions in #2487

[ssbarnea]

Apparently :latest is broken and reported on #2569