DOC: Update release instructions #52378
Conversation
|
Thanks @datapythonista |
| where our CI published them to the ``dist/`` directory in your local pandas copy. | ||
| You can use the script ``scripts/download_wheels.sh`` to download all wheels at once. | ||
|
|
||
| 7. Upload wheels to PyPI:: |
There was a problem hiding this comment.
What are your thoughts about trying pypa's actions to upload to pypi through a github action? https://github.com/pypa/gh-action-pypi-publish
There was a problem hiding this comment.
We should surely do that. Downloading and uploading the wheels is not a big deal, but no reason to do it manually.
There was a problem hiding this comment.
-1 on this. You can't delete wheels from PyPI if something goes wrong (e.g. some wheels build correctly and others fail) IIRC, so I would rather uploading stay as something manual.
There was a problem hiding this comment.
No big deal to automate this part, but if the only problem is not uploading all wheels if one or more fails, I think this can be constrained in the automation (like a CI step that depends on all the wheel generation builds).
There was a problem hiding this comment.
Maybe we can only trigger the second CI step that publishes after the GH release is published?
(I don't know how having a job depend on both the wheel builder workflow and a Github release to be published would work)
Another concerning scenario that I didn't mention before is that if you want to abort the release after the release is tagged, it's hard to do so now, since the wheel builds start as soon as the tag is pushed (You'd need to quickly hit cancel on the builds). I'm probably being overly pessimistic here though ...
Of course, I am not the release manager, so whatever works best for you works for me.
There was a problem hiding this comment.
I think having a build that we trigger manually is a good idea. One of the things that I don't like is uploading the wheels to the Anaconda repository, feels quite arbitrary, and makes things harder to understand for someone new to the release. But surely not a big deal. I guess the ideal would be if we could directly upload to the pypi once the wheels are ready, but we had a way to tell pypi when we want to make the new release available.
In any case, running the scripts locally is fine, not much difference between having tbat automated or not in practice. So, happy to keep things like they are for now until we find a solution we really like.
There was a problem hiding this comment.
Yeah, I think the dealbreaker is probably syncing the CircleCI wheel builds with it.
(The situation might get better if/when Github decides to make M1/aarch64 runners available).
I'm also not sure of what the point of the anaconda staging repository is anymore. I guess it's just more convenient to download from there than from a Github artifact?
Updating the release instructions since they still mention MacPython, and there were couple of code blocks that aren't rendering correctly.