FR: Encode flit-core build backend in uv

[chrisrodrigue]

I have previously floated the idea of uv defining/providing its own backend (see #3957) since the standard library does not provide this critical capability. I think that hatchling is a great build backend to use in the meantime and I am happy to see that it has been adopted as the default backend (#5527) when initializing projects.

I want to float the idea of base85 (or other more efficient) encoding a default backend in uv to bootstrap offline systems with a way to build when utilizing commands such as uv init or uv sync. Inspiration for this can be seen in the get-pip.py bootstrapping script.

Not only do I think that encoding/decoding a blessed backend will aid offline users, but I also think that it could improve performance by eliminating downloads for the transient build environment for users who elect to use the provided default.

While hatchling is a nice backend, it has numerous dependencies (packaging, pathspec, pluggy, tomli, trove-classifiers) that would need to be co-encoded, complicating maintenance and bloating the binary. I think flit-core is a great modern and minimalist alternative since it has no dependencies itself. It supports editable installations and a number of other common tasks.

[chrisrodrigue]

I’d be happy to implement this myself as a build time job that dynamically downloads and encodes the remote build backend when there’s a new version found.

But feel free to close this as an absolutely terrible idea 😄

[chrisrodrigue]

There’s a base116 crate that advertises a data size increase of only 1/6 (versus 1/4 for base85) by leveraging UTF-8 over pure ASCII encoding.

[zanieb]

I think we'd implement our own build backend before embedding a Python one into uv itself.

Related:

• FR: uv init --build-backend #6299

[zanieb]

It's a cool idea though. The offline use-case for #3957 is interesting.