Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #349 +/- ##
=======================================
Coverage 87.17% 87.17%
=======================================
Files 20 20
Lines 2019 2019
=======================================
Hits 1760 1760
Misses 259 259
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@wshanks, @jagerber48 This fixes the |
|
@newville What do you think? Should we try restarting the 3.2.4 publish workflow one time first to see if it goes through and then merge this in preparation for 4.0? Or try to get this into a revised 3.2.4? I don't object to anything here but I just wonder about if it should make it into 3.2.4 if it is not needed for the publish job to run. |
|
@wshanks @jagerber48 Yes, let's try it one more time. If it fails, I can build locally and should be able to push to PyPI. |
wshanks
left a comment
wshanks
left a comment
There was a problem hiding this comment.
Okay, I tried switching to a rule in the pypi-publish environment in the Environments section that restricted publishing to tags matching the pattern [0-9][0-9]*.[0-9][0-9]*.[0-9][0-9]* which some things I found on the internet said was the right pattern for this (fnmatch syntax) but I think they might have been wrong. I still got the same error about 3.2.4 not being allowed to publish. Rather than fiddle with that for now I just deleted the rule to allow publishing from any branch or tag and reran the workflow again and that time it seems to have worked. If anyone is interested, they can try to put the right syntax in to limit publishing only to the tags we expect to publish.
| - Adjusts the Sphinx configuration to allow for reproducible builds using | ||
| ``SOURCE_DATE_EPOCH``. | ||
| - Mark Python 3.13 and 3.14 as officially supported. | ||
| - Drop support for Python 3.8 |
There was a problem hiding this comment.
This has to move out of the 3.2.4 section now.
There was a problem hiding this comment.
3.2.4 is released. We need a new unreleased section and it will eventually go into, probably, 3.2.5. Or if this is the only change we want in 3.2.5 you can make a 3.2.5 section put it in there and we can release again today or tomorrow.
There was a problem hiding this comment.
Totally baffled. Did someone push 3.2.4 to PyPI? I did not.
The changes to pyproject.toml should be made at some point.
Closing.
There was a problem hiding this comment.
Sorry for the confusion. When I asked this:
Should we try restarting the 3.2.4 publish workflow one time first to see if it goes through and then merge this in preparation for 4.0?
I meant "should we try triggering the 3.2.4 publish workflow resulting in 3.2.4 being successfully published?" So that was what I tried and it did result in the previously identified commit (current master) being published as 3.2.4.
There was a problem hiding this comment.
The changes to pyproject.toml should be made at some point.
Can we just re-open this PR to keep the issue tracked so we don't forget about it? Totally independent of 4.0 timeline, just don't want to lose track of it since you've already done work for it.
There was a problem hiding this comment.
Unfortunately, this didn't get put into 3.2.4. But I will leave that up to you and @wshanks.... still a bit miffed that I started working on this untagged 3.2.4, and then3.2.4 got released despite working to fix this and waiting for comments.
There was a problem hiding this comment.
Hmm, I thought my message here was pretty clear that I was asking about trying to release 3.2.4 without the changes in this PR because they were not necessary for the release of 3.2.4 that we had already agreed on releasing (GitHub releases are tied to git tags).
Over the last year, my use of Uncertainties has been very minimal, so my efforts here are just recreational because I find it fun to maintain code that other people find useful. The amount of activity on this repo that evokes a negative emotion in me too high for a recreational project. There are enough other maintainers and you are more than capable of keeping this project in good shape. I am going to withdraw from maintainership at this time.
3 participants
fixes license settings in
pyproject.tomlto comply with the latest PyPA recommendations/requirements.pre-commit run --all-fileswith no errors