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).
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.
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.
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.
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).
Good. The state of affairs today is awful - what happened to "There should be one-- and preferably only one --obvious way to do it"?
They've been very outspoken about the intentions of uv being a similar tool to cargo from the start.
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.
uv is also a package manager and a build system.
https://docs.astral.sh/uv/concepts/build-backend/
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.
3 replies →
Am I just a package manager?
You pass butter
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.