-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build against pre-releases then stable releases. #472
Conversation
Codecov Report
@@ Coverage Diff @@
## main #472 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 18 18
Lines 1760 1760
Branches 213 213
=========================================
Hits 1760 1760
Flags with carried forward coverage won't be shown. Click here to find out more. |
@@ -13,7 +13,13 @@ jobs: | |||
|
|||
strategy: | |||
matrix: | |||
python-version: ["3.8", "3.9", "3.10", "3.11-dev"] | |||
python-version: | |||
# Build on pre-releases until stable, then stable releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment could be clearer.
IIUC this syntax is a workaround that will pick the latest available version (which is what we want), and the version could be an alpha, a beta, or a final/stable release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied this comment verbatim from jaraco/skeleton. I agree, the comment could provide a whole narrative about why it exists, but I try to be concise, to describe as briefly as possible the reason for the syntax, and then link to an issue that provides more context and tracks ultimate resolution.
If you'd like to suggest different wording, I'd be willing to apply that here and in jaraco/skeleton.
I think it's fine to add The good news: there's an open PR to fix actions/setup-python#213 that would allow us just to say |
Is it fine? I know for myself, I maintain hundreds of different projects, so each change requires a new commit in each repo, and leaves that repo stale until I get around to making that commit. Honestly, I'd like to get to a place where I can make zero changes to the repo and it will automatically pick up new Python versions, but cutting in half the number of commits required is a real time saver for me.
The bad news is that the maintainers are pushing back and insisting that the ugly workaround presented above is preferable. I hope by sharing this current-best-option and linking to the request, it will increase visibility and maybe help motivate a proper fix. Of course, this project doesn't need to be a part of my advocacy, so feel free to reject. I acknowledge, this syntax can and should go away if actions/setup-python#414 is merged and released and applied here. |
# Build on pre-releases until stable, then stable releases. | ||
# actions/setup-python#213 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like this? I also expanded the link to make it easier to open.
# Build on pre-releases until stable, then stable releases. | |
# actions/setup-python#213 | |
# This syntax will select the latest available releases | |
# including alpha, then beta, and finally stable releases. | |
# See https://github.com/actions/setup-python/issues/213 |
This is now merged and the workaround no-longer needed, so this PR can probably be closed. Note that there is an unrelated and ongoing issue about 3.12 (see #542), but after that is resolved we should be able to just use |
I use this technique in jaraco/skeleton (and derived projects) to reduce the number of commits necessary to adopt a Python version by 50% (by adopting each version during pre-release and then switching to stable once final is released). In actions/setup-python#213, I've reported the issue and I'm hoping that soon, "N.NN" will be sufficient to have the same behavior without having to require adding '-dev' and removing it later.
Feel free to reject if the ugliness outweighs the benefit.