Use hatch in github actions

[scverse-bot]

This is an attempt to move all CI scripts to hatch wherever possible. Not sure if we want that in all cases, but at least for running pytest it makes sense as it simplifies the CI script quite a bit and the pyproject.toml becomes the single point of truth on how to run tests.

• implement dependency groups according to PEP735

Cheers,
@grst

[github-actions]

A PR has been generated to the instance repo:
scverse/cookiecutter-scverse-instance#186

You can check out the PR to preview your changes
in an instance of the cookiecutter template. The PR will be kept in sync with
this PR automatically.

[flying-sheep]

also a good reason to use an app instead of a bot account

[Zethson]

Great!

I think @flying-sheep should ultimately approve this.

Generally, we are now really all-in on Hatch and I would not be surprised if uv expanded its scope in a year or two and we go all in on uv. It's still okay with me to commit more to Hatch now because well, we already use it in so many parts.

[flying-sheep]

Looking good, this certainly deduplicates things conceptually and makes everything easier to grasp.

The following collapsed section is #374

Details

Before I start: The “changes requested” is basically only because this PR should also get rid of the doc and test extras and move the doc deps and test deps into the respective hatch env configs. These extras are artifacts of using standard tooling in CI, and there is no need to expose them to users of the package when using Hatch in CI¹.

OK: there are two schools of thought here:

1. Before this PR: stick with standard tooling throughout everything to minimize lock-in with the build tool and keep things as simple as possible².
2. This PR: keep local development as close to what happens in CI

I think both approaches are valid. So this PR will make things as close to a local dev environment as possible at the cost of being slightly less debuggable if they break, e.g. there are now two environments in CI (system and hatch-test), not just the system one, but people should be used to that anyway.

Footnotes

1. There is discussion about introducing the concept of dev dependencies to standard Python project metadata: PEP 735. Until then, when a package wants to export a test utilities subpackage (e.g. testing.mypackage or mypackage.testing or so), the package can define a testing extra for users and use it from Hatch together with envs.hatch-test.dependencies like envs.hatch-test.features = ["testing"]. ↩

2. Note that I use “simple” in the same way a VW Beetle or Arch Linux are simple: “Use the most standard set of parts possible so everything is maximally debuggable when things break” ↩

[flying-sheep]

@Zethson see #331

I would not be surprised if uv expanded its scope in a year or two and we go all in on uv.

Hatch is currently by far the best environment manager (i.e. alternative to tox), this is why we use it. So keep in mind that unless uv expands into that territory, it’s no alternative to what we use Hatch for IMHO.

[flying-sheep]

OK, I made #375 for an alternative approach, let’s discuss there!

[flying-sheep]

I’m a bit confused why tests fail here. The .pre-commit-config.yaml contains biome tagged to 1.9.4, so why is 2.0.0b1 used here?

Apart from this, I think this looks great!

[grst]

I’m a bit confused why tests fail here. The .pre-commit-config.yaml contains biome tagged to 1.9.4, so why is 2.0.0b1 used here?

I don't get it either. The package-lock.json of the v1.9.4 release seems to pin the correct package versions. Is pre-commit doing something weird?

[flying-sheep]

Ah I got it, we’re asking for that. (I mean, yeah, the fact that pre-commit updates to pre-releases is weird, but nothing new)

cookiecutter-scverse/hooks/post_gen_project.py

Line 26 in a274031

run("pre-commit autoupdate -c .pre-commit-config.yaml".split(), check=True)

Maybe we should stop doing that? We keep the template updated nicely at all times anyway