dimagi/jsonobject

Alternatives to committed C files

Closed this issue · 1 comments

PeterJCLaw commented

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 commented

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.

  • 👍1