Manage entire Python projects and even Python itself with a single unified tool.

TL;DR: uv is an extremely fast Python package manager, written in Rust.

  • __init__ ( __init__@programming.dev ) 
    33·
    2 years ago

    Obligatory “there are now 15 competing standards”

    For real though, this looks interesting. I am a long time poetry user, I’ve been mostly happy with it but I do think it could stand to be a little faster. I’ll have to try this out sometime.

  • FizzyOrange ( FizzyOrange@programming.dev ) 
    13·
    2 years ago

    uv is fantastic. I would highly recommend it. I’ve used it in a quite complex environment, with no issues (quite an achievement!) and it’s about 10x faster than pip.

    I mean… I guess it’s not surprising given uv is written in Rust and pip is written in Python, but even so given pip is surely IO bound I was expecting something like 4x improvement. 10x is impressive.

    • Ephera ( Ephera@lemmy.ml ) 
      9·
      2 years ago

      The actual dependency resolution part, so where you figure out which versions of the dependencies can be used together, is actually notoriously CPU-bound.

      At least as far as I’m aware, you generally use a SAT solver for dependency resolution (unless you don’t care for correctness), and as Wikipedia puts it:

      Boolean satisfiability is an NP-complete problem in general. As a result, only algorithms with exponential worst-case complexity are known.

      There are quite sophisticated algorithms at this point, making use of heuristics and whatnot, but they’re still just backtracking algorithms at their core. And as Wikipedia puts it so fittingly again:

      backtracking is often much faster than brute-force enumeration

      You know shit’s inefficient, when the best thing to compare it to, is just randomly trying solutions.

      • FizzyOrange ( FizzyOrange@programming.dev ) 
        3·
        2 years ago

        you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)

        Actually Go’s dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I’m aware of. Python was designed before people realised that it’s dependency style was a mistake.

        https://research.swtch.com/vgo-principles

        • burntsushi ( burntsushi@programming.dev ) English
          6·
          2 years ago

          I’m on the uv team. I am quite partial to this approach as well. Alas, it’s difficult culturally to pull this off in a pre-existing ecosystem. And in the case of Python at least, it’s not totally clear to me that it would avoid the need for solving NP hard problems. See my other comment in this thread about simplifying PEP 508 marker expressions.

          Other than avoiding needing a SAT solver to resolve dependencies, the other thing I like about Go’s approach is that it makes it very difficult to “lie” about the dependencies you support. In a maximal environment, it’s very easy to “depend” on foo 1.0 but where you actually need foo 1.1 without issues appearing immediately.

  • Daniel Quinn ( danielquinn@lemmy.ca ) English
    10·
    2 years ago

    Having used it for work, I really don’t understand the appeal, especially when compared to tools like Poetry. Uv persists in the dependency on requirements.txt, doesn’t streamline the publishing process, and contrary to the claims, it’s not a drop-in replacement for pip, as the command line API is different.

    It’s really fast, which is nice if you’re working on a nightmare codebase with 3000 dependencies, but most of us aren’t, and Poetry is pretty damned fast.

    If uv offered some of what Poetry does for me, if at the very least we could finally do away with requirements.txt and adopt something more useable – baked into pyproject.toml of course – then I’d be sold. But this is just faster pip.

  • ahal ( ahal@lemmy.ca ) 
    7·
    2 years ago

    This is incredible. Truly hats off to the folks at Astral. Can’t wait to try all this out and replace all our old bespoke tooling.

  • hades ( hades@lemm.ee ) 
    6·
    2 years ago

    Is that a real problem? I’ve never considered that a python package manager should be or could be faster.

    To be fair, I don’t use python professionally.

    • FizzyOrange ( FizzyOrange@programming.dev ) 
      9·
      2 years ago

      Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces that to about 7 seconds. That’s a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time.

        • FizzyOrange ( FizzyOrange@programming.dev ) 
          4·
          2 years ago

          I dunno maybe once a week or so? We don’t actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.

          And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.

    • Midnitte ( Midnitte@beehaw.org ) English
      2·
      2 years ago

      I think the main focus is around building out the tool chain - I would think being fast is just a side benefit and the main benefit is being written as the same language as what they want to use for the rest of “cargo”