Add github workflow to build wheels

[ericpre]

Closes #357. Recently, I have been setting up building wheels for some package of the hyperspy framework using github CI and it works very well! In this PR, I have adapted the template to build wheels for traits.

Example of this github workflow running: https://github.com/ericpre/traits/actions/runs/247784316

Checklist

• Tests
• Update API reference (docs/source/traits_api_reference)
• Update User manual (docs/source/traits_user_manual)
• Update type annotation hints in traits-stubs

[mdickinson]

Thank you for this! I need to find time to look at it more closely.

We occasionally use tags for things other than releases, so I think we're not going to want to do this automatically on every pushed tag, and I'd want to be a bit cautious anyway about automated uploads to PyPI. OTOH, I don't really want to be manually uploading wheels one-by-one after they're built. The ideal workflow would look something like:

• push tag
• wheels are built automatically, but not (yet) uploaded to PyPI
• after reviewing the wheels, there's some sort of single manual interaction that says "yes, I approve this set of wheels for upload", and then all the built wheels are uploaded to PyPI

But as a first step we can leave out the last part and depend on manual wheel uploads.

[mdickinson]

Is cython needed here?

[corranwebster]

May be needed for this dependency: https://github.com/RalfG/python-wheels-manylinux-build

[ericpre]

As I understand this is necessary to play well with pep517.build. I haven't look into great details if this is strickly necessary but when I looked at it I came to the conclusion that is the most simple and - it seems - the most future proof, even if it adds one more configuration file!

[mdickinson]

Sure, I understand the necessity of the pyproject.toml, and for wheel and a minimum version for setuptools. It's specifically the cython requirement that I'm questioning. I think we shouldn't need this.

[ericpre]

Thank you for this! I need to find time to look at it more closely.

We occasionally use tags for things other than releases, so I think we're not going to want to do this automatically on every pushed tag, and I'd want to be a bit cautious anyway about automated uploads to PyPI. OTOH, I don't really want to be manually uploading wheels one-by-one after they're built. The ideal workflow would look something like:

• push tag

You could define specific prefix or suffix in the tag to filter/ignore tags which trigger this workflow (I have tried it):
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags

on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
    - '*'
    tags-ignore:
      - '*/*'
      - '*rc*'
      - '*-*'

• wheels are built automatically, but not (yet) uploaded to PyPI
• after reviewing the wheels, there's some sort of single manual interaction that says "yes, I approve this set of wheels for upload", and then all the built wheels are uploaded to PyPI

Not sure what will define the approval but this is running the test suite (or part of it) after installing the wheels this could be added to the workflow.
An alternative would be to split the workflow or add another one which does the upload to pypi but this would be more complicated.

But as a first step we can leave out the last part and depend on manual wheel uploads.

Indeed, all the wheels are in a single artifact zip file on github, so it is a matter of downloading this file, checking you are happy with these wheels and upload to pypi:
https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives

python -m twine upload your_folder/*

[ericpre]

I think that I will leave this PR to you now, my motivation for it is to give a good working base so that you can fiddle with it, so please free to do what you want with it: push to this branch, make another PR, etc!
It would be nice if this could be sorted though!

[mdickinson]

I think that I will leave this PR to you now,

Sounds good. If I can, I'll push further commits to your branch (at least partly to make sure that you end up with proper attribution in the GitHub history). Many thanks for making this PR - it's much appreciated and hugely helpful.

It would be nice if this could be sorted though!

Agreed, though I can't make any promises about how soon we'll find time to push this through.

[mdickinson]

Closing this in favour of #1404. Nevertheless, thank you very much @ericpre for this PR; it was instrumental in pushing this forward.