UV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).
As an outsider to python, I never got how a language who got popular for being simple, elegant and readable could end up with perhaps the most complex tooling situation (dependencies, envs, etc). Any time I glance at the community there seems to be a new way of doing things.
What caused python to go through these issues? Is there any fundamental design flaw ?
it’s my 1st attempt at reporting on CI downloads specifically. Interpreting this is more of an art than a science, I’d love to hear if others have ideas on what to do with this data!
It sounds like there are many Python users who have acclimated to the situation of needing three or more tools to work with Python and do not see the benefit or value of being able to do this all with one potentially faster tool.
While I understand that some have acclimated well to the prior situation and see no need to change their methods, is there really no objective self-awareness that perhaps having one fast tool over many tools may be objectively better?
I literally stopped writing Python for scripting a year ago - the distribution story was too painful. With LLMs, there's not much a dynamic language offers over something like Go even for quick scripting.
Also, on a new machine, I could never remember how to install the latest version of Python without fiddling for a while. uv solves the problem of both installation and distribution. So executing `uv run script.py` is kind of delightful now.
uv still has some issues, it cannot pull from global installations like pip, so on termux, something like tree sitter cannot be installed, because tree sitter is provided by apt/pkg
Uv and ruff are near feature complete and open source. It's very likely they'll survive in one way or the other and are already better than the tools they're meant to replace.
I'm at the point where I don't touch python without uv at all, if possible. The only bad is, now I want to use uv to install go and java and debian packages too ... :(
The ability to get random github project working without messing with system is finally making python not scary to use.
20 comments
[ 4.8 ms ] story [ 44.4 ms ] threadPython dependency management and environments have been a pain for 15 years. Poetry was nice but slow and sometimes difficult.
Uv is lightning fast and damn easy to use. It’s so functional and simple.
What caused python to go through these issues? Is there any fundamental design flaw ?
Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv.
I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part.
I'm not sure how big a project should be, before I feel pip is slow for me.
Currently, I have a project with around 50 direct dependencies and everything is installed in less than a min with a fresh venv and without pip cache.
Also, if I ever, ever needed lock files stuff, I use pipx. Never needed the hash of the packages the way it's done in package-lock.json.
Maybe, I'm just not the target audience of uv.
While I understand that some have acclimated well to the prior situation and see no need to change their methods, is there really no objective self-awareness that perhaps having one fast tool over many tools may be objectively better?
`uv install` = `uv sync`
`uv install rich` = `uv add rich`
Also, on a new machine, I could never remember how to install the latest version of Python without fiddling for a while. uv solves the problem of both installation and distribution. So executing `uv run script.py` is kind of delightful now.
Before that, I wouldn't want to be too dependent on it.
The ability to get random github project working without messing with system is finally making python not scary to use.
It gives you cross-platform binary packages, quickly (also written in Rust).