Helping Pint downstream projects

[hgrecco]

This is a call for help to provide the infrastructure for Pint Downstream projects. The main goal would be to provide guidelines and scripts so that downstream projects do no break when a new pint release comes out. It could look something like this

1. Release an alpha, beta and or rc versions of pint
2. Ask every downstream project to create at least 1 test that install pint's development version (e.g. pint install --pre pint)

It would also be nice to have

1. a way that downstream projects can trigger tests when Pint releases an alpha, beta and rc version
2. a dashboard that we can look at downstream projects CI status

Ideas of what is the best way to achieve this or something like this?

[hgrecco]

ping @dopplershift @jules-ch @MichaelTiemannOSC

[keewis]

Something that we have been doing in xarray's CI (and I believe MetPy is doing something similar) is regularly run a CI that installs the development versions of dependencies and runs the tests for that (automatically opening an issue if some tests failed).

The only disadvantage of this right now is that we couldn't quite figure out what to do if a dependency results in failing tests that take a long time to fix: as the automation will just update the initial issue, other, unrelated issues will pop up unnoticed (so someone still has to manually check that).

[hgrecco]

From Pint's point of view, my proposal is:

1. Release an rc version before the actual release
2. Trigger a CI run on downstream project (not sure how)
3. Check that all downstream projects are running
4. If true, release a new Pint Version.
5. If false and is a bug in Pint, fix it and go back to 1.
6. If false and is a bug in the downstream project, open an issue there.

The easy part is (1).
For (2), maybe we can use a github action to trigger a CI or open a PR in another repo. But I do not want to be invasive. In any case, maintainers will need to opt in.
For (3), I think we can create a markdown file in Pint's root with badges for all downstream projects. Maintainers could open a PR to incorporate new projects.

[dopplershift]

I'll say for MetPy, our "unstable build" job is running Pint directly from git master (since there haven't been RC's before). Our only problem, as mentioned by @keewis, is the behavior if multiple things start failing. But you should always be able to check the logs when that happens.

[hgrecco]

I actually like the way is way this is shaping up.

[hgrecco]

I created the following page to put some guidelines and keep everything in one place. What do you think?

[hgrecco]

I added this to pint-pandas