You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
How to specify best available Python minor version #213
I'd like to simply specify, "give me the best Python 3.10 you have". Ideally, "3.10" would indicate that specifier and include alphas and betas and release candidates until that version is stable at which point it would only include stable releases. I'd like not to have to specify "3.10.alpha - 3.10" (or similar) and later have to remove "alpha". If someone is specifying "3.10" before there's any stable release, couldn't that be simply interpreted to mean pre-releases until stable then just stable releases? It seems to me that's what 99% of users would require and would save a lot of toil around configs.
In jaraco/keyring@a5f055a, I discovered that "3.10.0-alpha - 3.10.99" may do what I'm after, but it sure would be nice if there were a simpler syntax. Also, will this syntax exclude alphas and betas after a stable version is released? I suspect not. Is there any syntax that can achieve what I describe above (most-stable, latest minor version)?
I don't think that PR does quite what I'd like. What I'd really like is to install the latest stable version, but to install the alpha or beta if no stable version is available. That is, I'd like to specify "3.8" and that would install 3.8.0aN until the beta is released, install 3.8.0bN until 3.8.0 is released, and then install stable releases of 3.8.X thereafter. I don't want to install 3.8.1bN.
Most importantly, I'd like for users not to have to change the specification between when 3.8.0bN is released and 3.8.0 is released. One change per repo per year should be more than enough to keep up with Python.
I could use the 3.8-dev, but it that seems awkward just to get beta versions. Why can't 3.8 mean get beta versions if available but get stable versions otherwise?
I totally support @jaraco claim as we really want to be able to setup a pipeline for a newer version of python before that is released and still continue to use it after it is released, without having to make another change to the repository to switch to stable.
This should be achievable by ensuring that aliases include unstable versions if not stable version match is found.
If someone is specifying "3.10" before there's any stable release, couldn't that be simply interpreted to mean pre-releases until stable then just stable releases? It seems to me that's what 99% of users would require and would save a lot of toil around configs.
I do agree with @jaraco statement so I went ahead and opened a PR.
The correct syntax to specify python 3.11 pre-releases until stable then just stable releases would be ~3.11.0-0 for now. This feels overly complicated for something as simple as that.
I just realized that by requiring this awkward syntax, it affects other reports downstream, such as when one uses the python version to tag codecov environments. Applying the prescribed workaround means that those codecov environments will display it as Python_~3.10.0-0 instead of Python_3.10.
I would just like to say that I support enabling to use preview Python versions without the -dev suffix, since it will reduce maintenance efforts. Thanks for the PR!
Activity
jaraco commentedon May 20, 2021
In jaraco/keyring@a5f055a, I discovered that
"3.10.0-alpha - 3.10.99"may do what I'm after, but it sure would be nice if there were a simpler syntax. Also, will this syntax exclude alphas and betas after a stable version is released? I suspect not. Is there any syntax that can achieve what I describe above (most-stable, latest minor version)?dmitry-shibanov commentedon May 31, 2022
Hello @jaraco. Thank you for your report. Sorry for the late response. I think this pull request should resolve your question.
jaraco commentedon May 31, 2022
I don't think that PR does quite what I'd like. What I'd really like is to install the latest stable version, but to install the alpha or beta if no stable version is available. That is, I'd like to specify "3.8" and that would install 3.8.0aN until the beta is released, install 3.8.0bN until 3.8.0 is released, and then install stable releases of 3.8.X thereafter. I don't want to install 3.8.1bN.
Most importantly, I'd like for users not to have to change the specification between when 3.8.0bN is released and 3.8.0 is released. One change per repo per year should be more than enough to keep up with Python.
I could use the
3.8-dev, but it that seems awkward just to get beta versions. Why can't3.8mean get beta versions if available but get stable versions otherwise?dmitry-shibanov commentedon Jun 1, 2022
Hello @jaraco. In this case I think if you need the latest version for a minor release you can try to specify it's as
~3.10.0.alpha.x.ssbarnea commentedon Jun 1, 2022
I totally support @jaraco claim as we really want to be able to setup a pipeline for a newer version of python before that is released and still continue to use it after it is released, without having to make another change to the repository to switch to stable.
This should be achievable by ensuring that aliases include unstable versions if not stable version match is found.
mayeut commentedon Jun 4, 2022
I do agree with @jaraco statement so I went ahead and opened a PR.
The correct syntax to specify python
3.11 pre-releases until stable then just stable releaseswould be~3.11.0-0for now. This feels overly complicated for something as simple as that.Add Python 3.11 into the matrix using workaround from actions/setup-p…
Add Python 3.11 into the matrix using workaround from actions/setup-p…
jaraco commentedon Jun 5, 2022
Confirmed that syntax does have the intended effect, if somewhat awkward a syntax. Thanks!
pypi-keyring: Autospec creation for update from version 23.5.1 to ver…
pypi-importlib_resources: Autospec creation for update from version 5…
Build against pre-releases then stable releases. Ref actions/setup-py…
jaraco commentedon Jun 20, 2022
I just realized that by requiring this awkward syntax, it affects other reports downstream, such as when one uses the python version to tag codecov environments. Applying the prescribed workaround means that those codecov environments will display it as
Python_~3.10.0-0instead ofPython_3.10.Build against pre-releases then stable releases. Ref actions/setup-py…
37 remaining items
EwoutH commentedon Oct 5, 2022
I would just like to say that I support enabling to use preview Python versions without the -dev suffix, since it will reduce maintenance efforts. Thanks for the PR!
pypi-importlib_resources: Autospec creation for update from version 5…
pypi-zipp: Autospec creation for update from version 3.8.1 to version…
Work around setup-python version not supporting 3.11 yet
pypi-jaraco.collections: Autospec creation for update from version 3.…
feat: Upgrade to Python 3.11 (#43)
pypi-tempora: Autospec creation for update from version 5.0.2 to vers…
pypi-jaraco.context: Autospec creation for update from version 4.1.2 …
Add Python 3.11 into the matrix using workaround from actions/setup-p…
Use '-dev' for every Python version. Ref actions/setup-python#213.
pypi-portend: Autospec creation for update from version 3.1.0 to vers…