Thanks for pointing that out. This is news to me. uv has been on my radar for a while and was considering switching to it as a better dependency manager. I didn't realise that it had ambitions beyond being "a better pip." At face value this is a real turn-off. Definitely violates the "do one thing and do it well" principle and puts it squarely in the "does complicated things that I want to avoid" (like poetry) category.
> "uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
This isn't exactly right: `uv build` executes a PEP 517[1] build backend interface, which turns a Python source tree into installable distributions. Those distributions can be sdists or wheels; in this sense, it's closer to `cargo build` than `cargo publish`.
The closer analogy for `cargo publish` would be `uv publish`, which also already exists[2]: that command takes an installable distribution and uploads it to an index.
TL;DR: `uv build` is a proxy for a build system, because that's how distribution construction is standardized in Python. I would not say it's analogous to `cargo publish`, since it's responsible for builds, not publishes.
cargo publish bundles your source files into a format (.crate) that can be distributed to other developers. This includes instructions for actually building the project at a later time. This is analagous to 'uv build' making an .sdist file.
I guess it gets more complicated with .whl since those can contain build artifacts as well and not just build instructions.
It's true that 'cargo publish' can also upload your .crate files to a remote repository, while uv breaks that functionality out into a separate command called 'uv publish' but I think that's neither here nor there on the difference between bundling the source and building the source.
Thanks for pointing that out. This is news to me. uv has been on my radar for a while and was considering switching to it as a better dependency manager. I didn't realise that it had ambitions beyond being "a better pip." At face value this is a real turn-off. Definitely violates the "do one thing and do it well" principle and puts it squarely in the "does complicated things that I want to avoid" (like poetry) category.
It gets difficult when you compare scripting languages to natively compiled languages, since some of the terminology is overloaded.
"uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
I would call this a packaging tool as opposed to a build system.
> "uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
This isn't exactly right: `uv build` executes a PEP 517[1] build backend interface, which turns a Python source tree into installable distributions. Those distributions can be sdists or wheels; in this sense, it's closer to `cargo build` than `cargo publish`.
The closer analogy for `cargo publish` would be `uv publish`, which also already exists[2]: that command takes an installable distribution and uploads it to an index.
TL;DR: `uv build` is a proxy for a build system, because that's how distribution construction is standardized in Python. I would not say it's analogous to `cargo publish`, since it's responsible for builds, not publishes.
[1]: https://peps.python.org/pep-0517/
[2]: https://docs.astral.sh/uv/guides/package/#publishing-your-pa...
cargo publish bundles your source files into a format (.crate) that can be distributed to other developers. This includes instructions for actually building the project at a later time. This is analagous to 'uv build' making an .sdist file.
I guess it gets more complicated with .whl since those can contain build artifacts as well and not just build instructions.
It's true that 'cargo publish' can also upload your .crate files to a remote repository, while uv breaks that functionality out into a separate command called 'uv publish' but I think that's neither here nor there on the difference between bundling the source and building the source.
1 reply →