Make a scikit-hep-bot

[matthewfeickert]

I want a scikit-hep-bot that is as cool as @pytestbot or @whedon! :)

c.f. pytest-dev/pytest#8148 and openjournals/joss-reviews#2823 for examples of what this kind of bot could do.

[matthewfeickert]

cc @eduardo-rodrigues and @henryiii as well to get more feedback.

[eduardo-rodrigues]

The JOSS one is clever ... scary :D. What would be the main goal for us? Across packages?

That's something totally different but it reminds me somehow of scikit-hep/scikit-hep.github.io#42 on a news section for the website.

[matthewfeickert]

What would be the main goal for us? Across packages?

I think that's unclear at the moment. I really like the way that pytestbot is able to setup a release through a request through a comment. I think that speaks a bit to my enjoyment in the release workflow that pyhf has at the moment which is automated through applying tags to PRs before we merge them. I think that we'd probably have to play around with the underlying technologies and systems to understand what things are capable of though and also if it would make sense to try to have a Scikit-HEP wide bot or if we would have them for individual projects.

[henryiii]

I really like simplicity and using setuptools_scm - I really don't see how a dedicated UI/tool, like clicking "make new release" in the GitHub UI or in the gh CLI is possibly harder than using bots and PRs. I probably should try it eventually, but boost-histogram, particle, etc. are all very easy to release.

And I've had to jump in and help fix the bots occasionally, at least on mplhep. :P

[kratsg]

We rely on setuptools_scm for doing the release. It's just kind of awkward when we want to release via PRs instead of pushing directly to master. We can't get around it, but we've reorganized our workflow such that a specifically-tagged PR will trigger a bump2version and push to master for us.

[henryiii]

Sorry, didn't mean to sound so negative there, and some of my issues would be solved by having a centralized bot. I work with a lot of repos, so steps that don't happen often and are hard to test like releases need to be simple and clean. I can't set up a complex system in all Scikit-HEP repos, and then maintain them.

setuptools_scm normally means you use your version control system as your versioning system. No versions in the repo files. At all. You hard code the version in setup.cfg and a bunch of other places, and therefore use bump2version, not setuptools_scm even if you use it for something else.

In boost-histogram, the release process is literally the GitHub release UI and nothing more. I have a bot that bugs me on each PR that doesn't update the changelog, so that stays up to date. The version numbers does not exist in the repo anywhere. Every commit gets a unique version based on the tag, the distance from the tag, and dirty vs. clean. The only manual step is I copy the release notes into the GitHub release, though I could setup actions to modify the release after the fact, I think.

[matthewfeickert]

Sorry, didn't mean to sound so negative there, and some of my issues would be solved by having a centralized bot.

No you're fine. I don't think anyone viewed it as being negative, just stating your views and workflows.

I can't set up a complex system in all Scikit-HEP repos, and then maintain them.

Yeah, this is why for doing releases for pylhe I just have it setup to trigger releases to PyPI through cutting releases on the GitHub UI. Very simple and it works.

setuptools_scm normally means you use your version control system as your versioning system. No versions in the repo files. At all. You hard code the version in setup.cfg and a bunch of other places, and therefore use bump2version, not setuptools_scm even if you use it for something else.

Yeah. In my mind the main way we use setuptools_scm is to ensure that the test release we push out to TestPyPI with each merge of a PR gets its own unique (dev) release number.

In boost-histogram, the release process is literally the GitHub release UI and nothing more. ... The version numbers does not exist in the repo anywhere. Every commit gets a unique version based on the tag, the distance from the tag, and dirty vs. clean.

Ah, I didn't realize this! This is actually quite interesting, I'll have to look through it.

I have a bot that bugs me on each PR that doesn't update the changelog, so that stays up to date.

We've been including the commit summary in the release notes thanks to the bot we have for a while, but I've only recently started curating them to be informative for readers. We really should start a CHANGELOG as well so that we have that on our docs website to make it easier for people to pinpout where, when, and why things got changed.