Pyenv: allow loose-er version specification?

[afeld]

I have a couple of related issues/suggestions:

First, I find myself needing to switch between Python 2 and Python 3 relatively frequently, but can never remember the specific version of each Python that I have, for specifying with pyenv. I'm coming from using Ruby Version Manager (RVM), which allows you to do:

rvm use 2.3.1

# or

rvm use 2.3
# which will switch to the latest 2.3.x

# or

rvm use 2
# which will switch to the latest 2.x.x

Would be really great to leverage that same shorthand in pyenv.

Relatedly, a static site I work on requires Python 2 as a transitive dependency for the build (through node-gyp, if you're curious). It's very unlikely that a patch (or even a minor) version bump would matter much for us, so while I would love to add a .python-version file to the project, I don't want to force my teammates to download _my exact specific version of Python_. Would be great for the .python-version file to accept the major or major+patch version, same as above.

If you wanted to get really fancy, these could even support the various version identifiers from PEP 440. Note that Node Package Manager (NPM) does a similar thing with their engines field, as does Rubygems with the requied_ruby_version.

Thanks!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Croydon]

Yes, please! It's unlikely that the patch version matters for us too much, but if it should at some point then we would need to update it in > 400 repositories.

Please allow to install the latest patch version with something like

pyenv 3.7

[smac89]

Related to https://github.com/pyenv/pyenv/issues/1364 and https://github.com/pyenv/pyenv/issues/1349

[captain-kark]

If the original feedback is considered:

pyenv install 2.7 should install 2.7, not the latest release of 2.7. I don't like implicit manner when specifying versions.

I would argue that this is a very good point to consider. Inferring a version other than what is provided when a patch-level version isn't included is definitely a smart move. Another comment by this same individual brings up other good points, which would need to be addressed.

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.

Personally, I would rather see something minimal, like pyenv install 3.7.x or pyenv install 3.7.* as a way of discarding an exact preference for some value in the semver's register, up to the minor version only. Pyenv should still require at least a major version set before accepting any special characters. Keeping it simple means that it will only target values that conform with the most basic usage of semver. Any version already identified as -latest would not be considered when leveraging this behavior.

As for sorting, detecting special characters should inform pyenv to break a given list of versions matching the prefix into a tuple of ints, which doesn't rely on string sorting and can be used to grab the actual latest version.

Are there other reasons not to include this in pyenv proper? Without this, every patch version through a minor version eventually ends up getting installed on my machine, given enough time.