Alternatives to committed C files

[PeterJCLaw]

Following from #187 (comment) (and #183 (comment)), I wonder if you'd be open to a alternative approaches?

Here's the approaches I can think of:

• build the .c files in CI and having that CI also build & push the package to PyPI (perhaps triggered by a tag being pushed)
• depend on cython at install time
• change the validation scripts to ignore whitespace and/or version number changes (but still pick up everything else)
• just add a regular (weekly?) CI run layered on top of the existing setup so the maintainers can see & fix the failures sooner
• add a regular (weekly?) CI run layered on top of the existing setup, which also commits the changes if there are any

Of these, I think the first one is the best -- it maintains the current easy of use for consumers of the package, while also making releases strictly easier for the maintainers (as CI now does more of what's currently manual).

I have a number of projects which have this setup (minus the .c file build part) and would be happy to put together a PR for this. (I don't know much about Travis though, so would probably do this as either Circle CI or GitHub Actions)

[dannyroberts]

I think I'm going to take this approach #199, where we Github Actions will attempt to rebuild C files using the latest Cython, and make a PR if there's a diff. On the off chance that we make a PR after a new version of Cython is released but before this automation runs, it'll run on any new PRs as well, and if there's a diff it'll create an automatic PR into the new PR reconciling the diff.