Add an option to resolve to prereleases in pyenv install/pyenv latest

[aphedges]

Description

• Platform information: macOS 12.6.3
• OS architecture: x86_64
• pyenv version: 2.3.13
• Python version: Python 3.12.0a5
• C Compiler information: Apple clang version 14.0.0 (clang-1400.0.29.202)
• Debug trace: trace.log

After the update to 2.3.13, I tried running pyenv install 3.12 to install the latest alpha, 3.12.0a5, but it failed with the error python-build: definition not found: 3.12. At some point after installing pyenv 2.3.11, I was able to use the same command to install 3.12.0a4. This therefore appears to be a regression.

[native-api]

That's intended. In fact, not excluding alphas from the get-go was an oversight.

[native-api]

We excluded unstable versions from auto-resolution on an assumption that otherwise, it would always resolve to an unstable version -- as the closest to the bleeding edge -- while most people are rather interested in the latest stable release.

[aphedges]

That's intended. In fact, not excluding alphas from the get-go was an oversight.

Good to know!

We excluded unstable versions from auto-resolution on an assumption that otherwise, it would always resolve to an unstable version -- as the closest to the bleeding edge -- while most people are rather interested in the latest stable release.

I didn't think about that. That wouldn't be a problem for most CPython versions (e.g., 3.7, 3.11) because there aren't pre-release versions for patch releases, but if the user entered 3, then they would get 3.12.0a5 instead of 3.11.2. As you said, this is undesired, and I agree.

I guess my thought is that something should be done in the case where there is no stable version available. If I enter 3.12, it can't resolve to a stable version because one won't exist until later this year. It would be nice if it could fall back to unstable versions in instances like this.

[native-api]

I guess my thought is that something should be done in the case where there is no stable version available. If I enter 3.12, it can't resolve to a stable version because one won't exist until later this year. It would be nice if it could fall back to unstable versions in instances like this.

I agree that for the likes of 3.12, getting an unstable version is expected -- if you 'know' that there's currently no stable version and you're okay with / specifically intend to get an unstable one.
But there's no way to tell either of that!
And still, once a release is done, you're suddenly back to ol' boring stable versions.

---

To make further argument either way productive, could you describe your use case? Then we can assess what can and cannot work for you.

[aphedges]

To make further argument either way productive, could you describe your use case? Then we can assess what can and cannot work for you.

My specific use case is installing the latest version of all minor CPython versions. I use the following command:

pyenv install --skip-existing 3.{7,8,9,10,11,12}

Without 3.12 being automatically set to 3.12.0a5, I need to manually look up what version is available and change my command to update it accordingly.

---

I agree that for the likes of 3.12, getting an unstable version is expected -- if you 'know' that there's currently no stable version and you're okay with / specifically intend to get an unstable one.
But there's no way to tell either of that!

I guess my assumption is that the user knows whether a Python version has been officially released or not. If they don't know, the pyenv output will state that a pre-release version is being installed, just as it does for stable patch versions.

And still, once a release is done, you're suddenly back to ol' boring stable versions.

That's exactly what I would want. Once 3.12 is released, it should resolve to a patch version, like it currently does for 3.11.

[native-api]

My best idea is a --prerelease switch for pyenv latest which would include prereleases -- but not -dev as otherwise it would always prevail. Not sure if we should fall back to -dev if there are no prereleases, either.

[native-api]

My best idea is a --prerelease switch for pyenv latest which would include prereleases

Maybe we should even only include prereleases.

[aphedges]

I think that --prerelease would be a good idea. I personally think that allowing pre-releases (instead of requiring them) makes more sense. I'm not sure of a use case where they should be required, and requiring them prevents a command like pyenv install --prerelease 3.11 3.12 from completing without an error.

---

Sorry for the long time to respond. I lost track of this issue.