chore: replace hatch environments with uv + ci scripts#4096
Conversation
|
i can understand how some folks might not like the churn but I'm +1 on this. we can always go back to hatch if we don't like plain uv. |
|
@maxrjones did you consider putting some of these scripts into a runner like a justfile? |
I considered nox/tox, but decided those were overkill after a chat with @chuckwondo. Just might be a better fit |
|
i mention |
| 'packaging>=22.0', | ||
| 'numpy>=2', | ||
| 'numcodecs>=0.14', | ||
| 'numcodecs>=0.14.1', |
There was a problem hiding this comment.
Zarr-Python was actually not compatible with numcodecs 0.14.0; the lowest supported version is 0.14.1 in reality due to the need for the soft dependency fixes in https://github.com/zarr-developers/numcodecs/releases/tag/v0.14.1.
|
At first glance I'm opposed to it because now we're maintaining a script. There's also now a cool vscode plugin for hatch environments: https://github.com/pypa/hatch-code I will set this to unread and look later though |
This PR switches to using uv + just + hatchling rather than uv + hatch + hatchling.
For context, I think it's sub-optimal to have environments managed by both hatch (for CI and in contributing guide) and uv (for typing). This PR shows how we could use only uv via a small set of bash scripts that make up for the missing task runner and environment names features in uv relative to hatch. The benefit is that all of our CI and developer workflows would be based on the exact same lock files for improved reproducibility.
I tried hatch's new lockfile support first, but it's platform specific so it doesn't help us much given we want cross-platform consistency.
I don't feel strongly about this PR, so totally fine being told that we should stick with the status quo.
TODO:
docs/user-guide/*.mdchanges/