Switch from hatch to uv for package and environment management

[binste]

What is your suggestion?

uv is now a Python packaging manager https://astral.sh/blog/uv-unified-python-packaging. For a while already it had a lot of useful functionality but now it has all the features we'd need to replace hatch. Paraphrasing @mattijn (correct me if I missed anything!), switching to uv might help us attract new developers. It's very likely that uv is much more popular than hatch, judging based on GitHub stars but also development activity and feature set. Due to this:

• It makes it easier for new Altair contributors to get started as they might already know it from other projects
• Or if a new contributor has not yet used it, it's likely that they are more interested in learning it

Have you considered any alternative solutions?

Poetry would be an alternative. uv seems closer to hatch so less of a switching cost and it just has a super fast solver and we have it already installed for the linting and formatting

[dangotbanned]

FYI we're already using uv for dependencies.

I'd support switching over fully if there was no loss of functionality.

A first step would be trying to replace pip and hatch in all the GitHub workflows.
They now have proper documentation - which was missing when I tried that out before

[joelostblom]

I'd support switching over fully if there was no loss of functionality.

I'm also on board with this

[jonmmease]

I think moving to uv sounds like a fine direction. One thing to throw out there is that I'm using pixi for VegaFusion, and will soon be using it for vl-convert. Pixi is a very similar idea, but has a few advantages for certain kinds of projects.

• It can pull dependencies from PyPI using en embedded copy of uv, so this is just as fast as plain uv
• It can also pull dependencies from conda-forge. This is really useful for non-python development dependencies. For example, in VegaFusion I configure Pixi to install Rust, Java, and Node.js from conda-forge so that these don't need to be installed at the system level.
• Pixi includes a cross-platform shell (based on Deno's shell) that it uses to evaluate tasks. This shell includes a bunch of basic unix commands like (cp, rm, pwd, cat, etc.) and it has access to any CLI dependencies installed from conda-forge. So you can write tasks as if you're on linux, and they work the same on Windows.
• Pixi tasks can depend on other tasks, and they support hash-based caching to intelligently skip running the parent tasks when not needed.

Altair development doesn't require any non-Python dependencies, so the advantage of Pixi over uv isn't that strong, but wanted to mention it as an alternative to at least consider.

[dangotbanned]

@jonmmease I'm quite keen to use pixi in vl_convert as you know vega/vl-convert#186

Altair development doesn't require any non-Python dependencies, so the advantage of Pixi over uv isn't that strong, but wanted to mention it as an alternative to at least consider.

I would say the advantages you listed are interesting but not sure how they'd benefit altair.

Also from reading the docs, it seems to be missing building & publishing.
Not fully sure how that works in altair, but I thought hatch & uv both had these features?

[jonmmease]

Yeah, for building a publishing you still use python -m build and twine. And I have no objection to using uv (or staying with hatch for that matter).

[dangotbanned]

FYI we're already using uv for dependencies.

I'd support switching over fully if there was no loss of functionality.

A first step would be trying to replace pip and hatch in all the GitHub workflows. They now have proper documentation - which was missing when I tried that out before

Related

• https://github.com/narwhals-dev/narwhals/blob/e9afffd233ed4b4df5364dc8c16ba00e16f86871/.github/workflows/downstream_tests.yml
• ci: adopt uv narwhals-dev/narwhals#682 (comment)
• [Enh]: Use offical astral-sh/setup-uv@v2 github action and enable caching in the CI narwhals-dev/narwhals#955

[dangotbanned]

Noting here that switching to uv from pip in build.yml may unblock https://github.com/vega/altair/actions/runs/10861487260/job/30143440337?pr=3591

• ci: Support Python 3.13 #3591

If I've understood geopandas/pyogrio#450 correctly, installing pyogrio with conda instead of pip avoided the same error