rebuild c files on cython==0.29.23

[czue]

#182 (comment)

Out of curiosity what's the value this test provides?

[czue]

✅

[dannyroberts]

Out of curiosity what's the value this test provides?

Yeah good question. I think the value is that since the .c files are conceptually redundant with the pyx files they're built from—i.e. they're really a build artifact that we're committing directly to the codebase—it's important to know that the .c files actually do match the .pyx files they're built from. A side effect of it though (and there are pros and cons to this) is that when there's a new version of cython, then the build output changes for a different reason that's unrelated to whatever recent change a dev just made and PR'd. You've experienced the cons more or less, but here are the pros of the way it's set up

• Pro of committing the .c build artifacts are that we don't then need a CI toolchain that builds the artifacts from which we need to fetch them to release to pypi. (And the .c files do need to be included in what we send to pypi.)
• Pro of not pinning cython are that we end up staying on the latest version of cython

All that said, this isn't a defense exactly of the current system. For example we could use dependabot to make a PR to update cython instead, if we enable that and move the cython dependency to a format that dependabot would recognize. I more just wanted to make what's behind the current system transparent

[czue]

Cool, thanks for the detailed explanation!

[dannyroberts]

My pleasure. Thanks for the fix!