Skip to content
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

Add workflow for building and uploading wheels #1404

Merged
merged 6 commits into from
Jan 18, 2021

Conversation

mdickinson
Copy link
Member

@mdickinson mdickinson commented Jan 16, 2021

This PR adds a workflow for automatically building and uploading source distribution and wheels to PyPI when a Traits release is published.

Still to do:

  • iterate on the workflow until it's working as far as the twine upload step. That step is expected to fail due to invalid permissions
  • change the workflow trigger so that it runs on publication of a release rather than on PR commits
  • provide valid permissions

Notes

  • On macOS, the Python builders we use have MACOSX_DEPLOYMENT_TARGET=10.14, so the wheels built won't work on macOS versions earlier than 10.14
  • On Linux, we build manylinux1 and manylinux2010 wheels. That's probably good enough for now, but at some point in the future we'll likely also want manylinux2014 wheels.
  • On Windows (and only on Windows), we build wheels for 32-bit Python as well as for 64-bit Python. I'm assuming that there's essentially zero demand for 32-bit wheels on Linux.
  • No provision for ARM-based Macs yet.

Closes #357.

@mdickinson mdickinson marked this pull request as ready for review January 16, 2021 11:27
@mdickinson
Copy link
Member Author

This PR is ready for review. I haven't yet provided values for the PyPI upload environment variables, in case we want to do any more tinkering with the workflow prior to merge. I'll add the secrets once the PR is finalised and approved for merge.

@mdickinson
Copy link
Member Author

Suggestion for reviewers: in addition to reviewing the workflow itself, review the workflow output for commit d6128c0. Then review the changes since that commit to verify that I haven't changed anything that would invalidate the workflow.

Copy link
Contributor

@rahulporuri rahulporuri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.


on:
release:
types: [published]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you want to add a prereleased to this list to test this workflow/wheels with a 6.2.0 prerelease?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I think published covers pre-releases as well as releases. The documentation isn't 100% clear and leads you down a maze of twisty little passages, but I ended up here: https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#release

And that says:

  • prereleased: a pre-release is created
  • published: a release, pre-release, or draft of a release is published

In addition, the main page https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release says:

Note: The release event is not triggered for draft releases.

So I think just published is what I need here.

@mdickinson
Copy link
Member Author

Valid secrets have been added; this PR should be ready to merge.

@mdickinson mdickinson merged commit cc01cbd into master Jan 18, 2021
@mdickinson mdickinson deleted the build/wheel-build-workflow branch January 18, 2021 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider uploading wheels to pypi to avoid needing compilation when installing
3 participants