Comment by rcarmo
2 days ago
This feels like feature creep. I've been using uv more and more over the past year (mostly because I work with projects that use it) and although I like it and recognize the advantages, it is still not my first choice, and this kind of thing isn't going to help that...
What's wrong with this approach specifically? Go does it this way. Rust does it this way. Elixir does it this way. It reduces the toil in setting up and using projects in those ecosystems substantially. It unifies community effort behind a common set of tools and provides beginners and experts alike with a shared entrypoint to projects.
What's wrong with the approach is that it goes against basic principles of the Python ecosystem. Python has always followed the policy of standardising mechanisms and allowing implementations to develop and peacefully coexist. The Python way fosters diversity of implementations. Note that uv itself would not be a reasonable project if not for Python's approach to diverse tooling.
You cite good examples where other languages have chosen to standardise tooling. We can discuss the pros and cons of that choice. But it is a choice, and Python already made a different choice.
All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff` as a linter and `black` as a formatter, or `ruff` for both, or whatever. Here, similarly, you can use `uv` with `ruff`, or bring your own formatter. It's intentional for us that you can use the pieces that you want, and interoperate with other tools. But it's also intentional that we want using our tools _together_ to be a great experience. I think we can achieve both of these things. Or, at least, we're going to try.
I’m not sure I agree with this. If anything, a diversity of implementations coexisting is against the basic principles of Python.
> There should be one-- and preferably only one --obvious way to do it.
- PEP20 - The Zen of Python
2 replies →
uv exists because Python's default packaging situation is a mess. There was supposed to be one way to do it, pip, but then it became pip + venv because it's too unreliable otherwise, but that's still bad.
You’re free to build your own Rube Goldberg machine, some of us just want to use well crafted tools and be done with it.
what if somebody happens to not like the Basic Principles of the Python Ecosystem? most languages do quite well with a single package manager, it's getting harder to argue that Python's need to introduce a new one every year is actually a good thing
"The basic principles of the Python ecosystem" are a dumpster fire to anyone who isn't already desensitized to the situation. Just like 'uv' as a whole, this seems like a meaningful step towards making Python a little less terrible to actually use, and should be applauded.
But astral is a startup, they don't really want to coexist I guess.
2 replies →
One thing I wonder about is what happens in pyproject? Do you use tool.ruff/tool.ruff.format or tool.uv.format or what? Are people who only know "uv format" supposed to understand that part? Does ruff start honoring tool.uv.format? Which have priority over which in search. Does it behave differently when you run uv format vs ruff format? etc
What is your first choice?
Pip, because it introduces no third-party software. This is critical in regulated industries.
Oh boy, you're gonna have a really bad day when you figure out what "pip install" does.
What is “third party” here? Pip and UV are both external dependencies used to install other external dependencies. What makes them different from each other, or from the other dependencies you are using them to install?
2 replies →