3 ms·

All of these issues are kind of solved by uv. It took the Python community a long time to realize that Python isn’t a great language for writing Python tooling.

All of these issues are kind of solved by uv. It took the Python community a long time to realize that Python isn’t a great language for writing Python tooling. uv solves the bootstrapping problem, and its resolver is infinitely faster than poetry’s or pipx’s. It’s hard to recommend anything else these days.

zahlman 2y ago
I've said many times that the problems solved by uv aren't really caused by using Python as an implementation language - they're primarily caused by the design of the existing tools. Resolvers in particular are constrained by many things that aren't the implementation language: the algorithm (is it making likely-to-succeed guesses first?), how thorough the resolver tries to be, the approach to caching.... (Of course your network connection also matters, but tools can't really do anything about that. Yes, I do count that as part of resolution because you can't actually get all the necessary metadata in one shot because of the way that the packaging standards and PyPI work.) But I don't have the kind of hard numbers I'd really like in order to make that argument properly. Hopefully I will by the end of the series, since I'll also be working on Paper. Bootstrapping isn't a real problem unless you actually want to get Python itself (not a virtual environment; those are trivial) and find the standard approaches insufficient. I have already worked out how Paper will bootstrap itself - and I expect it to end up being much smaller than Pip, never mind the full Pipx package or a compiled uv binary. I guess hardly anyone cares about saving a few megabytes of disk nowadays, but it's a real annoyance for me (and the planned subject of another post, not in this series). If you like having an opinionated, integrated workflow tool, uv comes highly praised. I personally am much more in favour of the Unix philosophy. If you use uv only to install applications and libraries then that seems like a waste to me.

zahlman 2y ago

I've said many times that the problems solved by uv aren't really caused by using Python as an implementation language - they're primarily caused by the design of the existing tools. Resolvers in particular are constrained by many things that aren't the implementation language: the algorithm (is it making likely-to-succeed guesses first?), how thorough the resolver tries to be, the approach to caching.... (Of course your network connection also matters, but tools can't really do anything about that. Yes, I do count that as part of resolution because you can't actually get all the necessary metadata in one shot because of the way that the packaging standards and PyPI work.) But I don't have the kind of hard numbers I'd really like in order to make that argument properly. Hopefully I will by the end of the series, since I'll also be working on Paper. Bootstrapping isn't a real problem unless you actually want to get Python itself (not a virtual environment; those are trivial) and find the standard approaches insufficient. I have already worked out how Paper will bootstrap itself - and I expect it to end up being much smaller than Pip, never mind the full Pipx package or a compiled uv binary. I guess hardly anyone cares about saving a few megabytes of disk nowadays, but it's a real annoyance for me (and the planned subject of another post, not in this series). If you like having an opinionated, integrated workflow tool, uv comes highly praised. I personally am much more in favour of the Unix philosophy. If you use uv only to install applications and libraries then that seems like a waste to me.