Code formatting comes to uv experimentally

Why does a package manager need a formatter at all?

Is cargo just a package manager? Go?

Am I just a package manager?

Cargo is a hybrid of package manager and build system. So it has frontend fommands wrapping a formatter and loads of other stuff, like code linters, as part of the build system. I've used cargo to build projects even when they have no dependencies and I don't plan to bundle them up and publish them as crates.

I don't know much about go.

Ok, but we will go a step further and also integrate the remaining of ruff features? Because we have `go vet`. Does it even make sense to have the linter integrated too?

I am not sure I like this either. I think linter and formatter are more like developer dependencies, especially because both formatter and linters are generally things that you want to lock to a specific version to avoid e.g. CI failures or mass changes when a version is updated. But I can understand that having a formatter always available may be nice.

uv is also a package manager and a build system.

https://docs.astral.sh/uv/concepts/build-backend/

You pass butter

Careful, we're going to end up with some integrated development environment, that has all these things working nicely together!

This is starting to sound like uv is a trojan horse that was introduced as a package manager and is now seeking to replace the diverse python ecosystem with a totalizing approach that is anathema to the the python way (standardize protocols, accommodate diverse implementations).

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.

They've been very outspoken about the intentions of uv being a similar tool to cargo from the start.

Good. The state of affairs today is awful - what happened to "There should be one-- and preferably only one --obvious way to do it"?

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.

I would say that `cargo publish` uploading a package to a remote index (like crates.io) is its primary purpose. I've been writing Rust for about 7 years now and I don't think I've ever seen someone use it primarily to generate a `.crate` file without uploading it somewhere.