13 ms·

uv: An extremely fast Python package and project manager, written in Rust

• mh- 1y ago
  Started using this recently for personal stuff on my laptop. When you're used to pip, it's just confusingly fast. More than once I thought maybe it didn't work because it returned too quickly..
• eats_indigo 1y ago
  Love UV! Also love Ruff from the Astral team. We just cut our linting + formatting across from pylint + Black to Ruff. Saw lint times drop from 90 seconds to < 1.5 seconds. crazy stuff.
  • greatgib 1y ago
    Until the moment you will realize that ruff perform only a part of pylint checks and that very obvious mistakes can go through easily like code that can't run because of an obvious error.
    • oblio 1y ago
      Which checks is it missing?
      • js2 1y ago
        Many, but it also has many that pylint does not. I use them both, ruff first, followed by pylint. https://docs.astral.sh/ruff/faq/#how-does-ruffs-linter-compare-to-pylint https://docs.astral.sh/ruff/faq/#how-does-ruffs-linter-compa... https://github.com/astral-sh/ruff/issues/970 https://github.com/astral-sh/ruff/issues/970
        • _flux 1y ago
          Seems though mypy/pyright/pyre/pyrefly or the future ty could bridge the gap, if one is writing typed python?
          • greatgib 1y ago
            The big question will be to know if tools will still be fast once they will have added the tests that are missing.
    • jsmeaton 1y ago
      Do you have an example of this?
      • js2 1y ago
        It's in the documentation: https://docs.astral.sh/ruff/faq/#how-does-ruffs-linter-compare-to-pylint https://docs.astral.sh/ruff/faq/#how-does-ruffs-linter-compa... https://github.com/astral-sh/ruff/issues/970 https://github.com/astral-sh/ruff/issues/970
• pu_pe 1y ago
  Tried uv a while ago and I was shocked by how fast and easy it is to use. There's basically no reason to use pip anymore, and if you're using only Python there's basically no reason to use conda either.
  • oceansky 1y ago
    It seems to make pyenv and poetry droppable too.
    • findalex 1y ago
      and pipx.
• psunavy03 1y ago
  I'm sold. Never going back to pip/twine/requirements.txt again if I don't have to. I have several projects that all share a common wheel hosted on an internal GitLab instance, and I was able to replace like 10 lines of YAML with just "uv build" and "uv publish." Importing is quick and easy, and you can see what your core dependencies are as opposed to everything just being in one mess of a requirements.txt.
• leonheld 1y ago
  I adore the uv add <mydependencies> --script mycoolscript.py And then shoving #!/usr/bin/env -S uv run on top so I can run Python scripts easily. It's great!
  • intellectronica 1y ago
    It's so cool. I now habitually vibe-code little scripts that I can immediately run. So much nicer than having to manage environments and dependencies: - https://everything.intellectronica.net/p/the-little-scripter https://everything.intellectronica.net/p/the-little-scripter - https://www.youtube.com/watch?v=8LB7e2tKWoI https://www.youtube.com/watch?v=8LB7e2tKWoI - https://github.com/intellectronica/ez-mcp https://github.com/intellectronica/ez-mcp
  • kristjansson 1y ago
    e: I misread your example, disregard below irrelevant pattern matching of 'uv add --script' to 'uv add' in the project context! ~~That mutates the project/env in your cwd. They have a lot in their docs, but I think you’d like run --with or uv’s PEP723 support a lot more~~ https://docs.astral.sh/uv/guides/scripts/ https://docs.astral.sh/uv/guides/scripts/
    • misnome 1y ago
      PEP723 support is exactly what the poster is using?
      • kristjansson 1y ago
        Ach, missed the --script, thanks.
  • jsilence 1y ago
    Using this trick with Marimo.io notebooks in app-mode. Instant reactive reproducible app that can be sent to others with minimal prerequisites (only uv needs to be installed). Such a hot combo.
  • simonw 1y ago
• colechristensen 1y ago
  So how does Astral plan to make money?
  • SSchick 1y ago
    Apparently VC(1) so far, I'd assume there will be LTS support contracts and tailored enterprise features down the line; for the moment I'd assume it's just a bunch of talented devs fixing problems they've been tired off / see as long term existencial threats to the python ecosystems. 1: https://old.reddit.com/r/Python/comments/12rk41t/astral_nextgen_python_tooling/ https://old.reddit.com/r/Python/comments/12rk41t/astral_next...
  • serjester 1y ago
    Anaconda makes on the order of 100M a year “solving” data science package management. I would argue it has a significantly worse product, attacking a much smaller part of the ecosystem. It seems easy to imagine Astral following a similar path and making a significant amount of money in the process.
    • colechristensen 1y ago
      Anaconda isn't free. I don't want to pay per-seat fees for slightly improved versions of open source tools which is why I'm very skeptical of Astral and uv. One day they're going to tell me I have to pay $10/month per user and add a bunch of features I really don't need just because nobody wants to prioritize the speed of pip. And most of that fee isn't going to go towards engineers maintaining "pip but faster", it's going to fund a bunch of engineers building new things I probably don't want to use, but once you have a company and paying subscribers, you have to have developers actively doing things to justify the cost.
      • serjester 1y ago
        Enterprises don't care about faster, but they do care an enormous amount about security. Astral is very well positioned here.
    • 1y ago
• putna 1y ago
  unfairly fast
• theLiminator 1y ago
  uv and ruff are a great counterexample to all those people who say "never reinvent the wheel". Don't ever do it just for the sake of doing it, but if you have focused goals you can sometimes produce a product that's an order of magnitude better.
  • eviks 1y ago
    They didn't reinvent the wheel, "just" replaced all the wood with more durable materials to make it handle rotation at 10 times the speed
    • socalgal2 1y ago
      I'd be curious to know exactly what changed. Python -> Rust won't make network downloads faster nor file I/O faster. My naive guess is that all the speed comes from choosing better algorithms and/or parallelizing things. Not from Python vs Rust (though if it's hard to parallelize in Python and easy in rust that would certainly make a difference)
      • the8472 1y ago
        NVMe hungers, keeping it fed is hard work. Doing some serial read, decompress, checksum, write loop will leave if starved (QD<1) whenever you're doing anything but the last step. Disk IO isn't async unless you use io_uring (well ok, writeback caches can be). So threads are almost a must to keep NVMe busy. Conversely, waiting for blocking IO (e.g. directory enumeration) will keep your CPU starved. Here too the answer is more threads.
      • jerpint 1y ago
        From just my observations they basically parallelized the install sequence instead of having it be sequential (among many other optimizations most likely)
      • ekidd 1y ago
        I've translated code from Ruby to Python, and other code from Rust to Python. Rust's speed advantages typically come from one of a few places: 1. Fast start-up times, thanks to pre-compiled native binaries. 2. Large amounts of CPU-level concurrency with many fewer bugs. I'm willing to do ridiculous threading tricks in Rust I wouldn't dare try in C++. 3. Much lower levels of malloc/free in Rust compared to some high-level languages, especially if you're willing to work a little for it. Calling malloc in a multithreaded system is basically like watching the Millennium Falcon's hyperdrive fail. Also, Rust encourages abusing the stack to a ridiculous degree, which further reduces allocation. It's hard to "invisibly" call malloc in Rust, even compared to a language like C++. 4. For better or worse, Rust exposes a lot of the machinery behind memory layout and passing references. This means there's a permanent "Rust tax" where you ask yourself "Do I pass this by value or reference? Who owns this, and who just borrows is?" But the payoff for that work is good memory locality. So if you put in a modest amount of effort, it's fairly easy to make Rust run surprisingly fast. It's not an absolute guarantee, and there are couple of traps for the unwary (like accidentally forgetting to buffer I/O, or benchmarking debug binaries).
• lucideng 1y ago
  UV solved any issue I had getting python to run on a machine. Just `git clone someproject`, `uv run somescript.py`, then mic drop and walk away.
  • oezi 1y ago
    `uvx` directly from the repo also works nicely
  • akx 1y ago
    Why even `git clone`? With a properly packaged project, you can just `uvx --from=git+https://github.com/akx/bindl.git https://github.com/akx/bindl.git bindl`
• Vaslo 1y ago
  Moved to this and have no need for anything else, especially since uv pip install whatever works with uv and is faster than pip (though I usually use uv add).
• oezi 1y ago
  I continue to be puzzled why sometime running uvx (uv tool run) will redownload all dependencies even though it just downloaded them for another tool. Downloading torch 15 times per day gets old even on 500 mbits
  • holysoles 1y ago
    Might be worth opening an issue, the project states it aims to aggressively cache dependencies: https://docs.astral.sh/uv/concepts/cache https://docs.astral.sh/uv/concepts/cache Maybe that functionality isnt implemented the same way for uvx. You could try this equivalent command that is under "uv run" to see if it behaves differently: https://docs.astral.sh/uv/concepts/tools/#relationship-to-uv-run https://docs.astral.sh/uv/concepts/tools/#relationship-to-uv...
    • oezi 1y ago
      I haven't been able to find any kind of rhyme or rhythm to it, so I don't know how to explain when it happens or how to better debug it for a bug report.
  • veganjay 1y ago
    Initially, I used `uv tool run <name>`, but later discovered `uv tool install <name>`. The `install` command downloads dependencies once and caches them for future use. It is similar to how `pipx install <name>` works. e.g. $ uv tool install asciinema $ asciinema play example.cast
• xnyan 1y ago
  Worth using just for 'uv pip' as a replacement for pip on the grounds of being much much faster. I've completely switched to uv and I can't imagine ever going back to pip for this and lots of other outstanding features.
• egonschiele 1y ago
  uv has become essential for me. conda and virtualenv never worked smoothly for me, but uv was easy and "just worked" from day 1.
• polivier 1y ago
  The first time I used `uv`, I was sure that I had made a mistake or typed something wrong because the process finished so much more quickly than anything I had ever experienced with `pip`.
  • baby 1y ago
    Same here lol! The experience is so smooth it doesn't feel like python
    • johnfn 1y ago
      That makes sense, because it's Rust. :)
  • nialse 1y ago
    Likewise. I was skeptical, then I tried it and won’t go back.
  • augustflanagan 1y ago
    I just had this same experience last week, and was certain it wasn’t working correctly as well. I’m a convert.
  • tux3 1y ago
    I've sometimes had uv take up to 200ms to install packages, so you could feel a slight delay between pressing enter and the next shell prompt You don't have that problem with Poetry. You go make a cup of coffee for a couple minutes, and it's usually done when you come back.
    • Numerlor 1y ago
      It's funny when the exact same thing was probably said about pipenv and poetry
      • icedchai 1y ago
        I've had poetry sit there for minutes resolving dependencies at a previous company. I thought something was broken... it probably was... but it did eventually complete.
• incognito124 1y ago
  uv is almost perfect. my only pet peeve is updating dependencies. sometimes I just want to go "uv, bump all my dependencies to the as latest version as possible while respecting their constraints". I still haven't found an elegant way to do this, but I have written a script that parses pyproject.toml, removes the deps, and invokes `uv add --upgrade` with them. other than that, it's invaluable to me, with the best features being uvx and PEP 723
  • jmtulloss 1y ago
    Does `uv lock —upgrade` not do what you want?
    • incognito124 1y ago
      Unfortunately, no. Only `uv.lock` gets updated, but the dependencies in `pyproject.toml` are frozen at their original constraints. What I want is, if my project depends on `package1==0.4.0` and there are new versions of package1, for uv to try install the newer version. and to do that for a) all the deps, simultaneously, b) without me explicitly stating the dependencies in the command line since they're already written in the pyproject.toml. an `uv refresh` of sorts
      • wtallis 1y ago
        > What I want is, if my project depends on `package1==0.4.0` and there are new version of package1, for uv to try install the newer version. I think you're just specifying your dependency constraints wrong. What you're asking for is not what the `==` operator is for; you probably want `~=`.
      • Eridrus 1y ago
        Why not depend on package1>=0.4.0 rather than specifying an explicit version? Then uv will upgrade it to the latest version. pyproject.toml is meant to encode the actual constraints for when your app will function correctly, not hardcode exact versions, which is what the lockfile is for.
• tandav 1y ago
  Still no option to store virtual envs outside projects after a year https://github.com/astral-sh/uv/issues/1495 https://github.com/astral-sh/uv/issues/1495
  • sitic 1y ago
    This is the most important missing feature to me as well. I've written a lightweight replacement script to manage named central virtual envs using the same command syntax as virtualenvwrapper. Supports tab completion for zsh and bash: https://github.com/sitic/uv-virtualenvwrapper https://github.com/sitic/uv-virtualenvwrapper
    • globular-toast 1y ago
      Inspired by this I made a similar thing for direnv: https://github.com/georgek/dotfiles/blob/01fb53619adc7269824e9dabae5a1a62618a9d40/direnv/.direnvrc#L73 https://github.com/georgek/dotfiles/blob/01fb53619adc7269824... A problem I have now, though, is when I I jump to def in my editor it no longer knows which venv to load because it's outside of the project. This somehow used to work with virtualenwrapper but I'm not sure how.
  • TaroEld 1y ago
    The UV_PROJECT_ENVIRONMENT variable can be used as a workaround: https://docs.astral.sh/uv/concepts/projects/config/#project-environment-path https://docs.astral.sh/uv/concepts/projects/config/#project-...
  • akx 1y ago
    `UV_PROJECT_ENVIRONMENT` works fine for that. That's what I use for my venv-managing Fish functions: https://gist.github.com/akx/c357bbda9facbe41f08747a2622795c4 https://gist.github.com/akx/c357bbda9facbe41f08747a2622795c4
• forrestthewoods 1y ago
  Here’s my #1 complaint about uv: I’m new to the python ecosystem. I don’t know anything about pip or the existing tools. I would love for uv to at least have documentation and a user guide that doesn’t assume knowledge of the old bad tools that uv replaces. Perhaps uv will continue its ascendancy and get there naturally. But I’d like to see uv be a little more aggressive with “uv native” workflows. If that makes sense.
  • wrs 1y ago
    That exists! [0] But IMHO the guides should be linked in big text as the first thing on the homepage. Right now you have to read through a bunch of meaningless comparative bullet points and reassurances then click a few times to get to the guides. If it weren’t for everyone telling me I need to switch, I might not have had the patience to find them. [0] https://docs.astral.sh/uv/guides/ https://docs.astral.sh/uv/guides/
• carlosdp 1y ago
  I love uv, not just for local development, but it also makes it WAY easier to manage python environments you setup for running python workers / user code in the cloud.
• 6ak74rfy 1y ago
  UV is fast, like FAST. Plus, it removes the need for pyenv (for managing different Python versions) and pip for me. Plus, no need to activate env or anything, `uv run ...` automatically runs your code through the env. It's a nice software.
  • nomel 1y ago
    > Plus, it removes the need for pyenv I don't see a way to change current and global versions of python/venvs to run scripts, so that when I type "python" it uses that, without making an alias.
    • adamckay 1y ago
      If they're your scripts (i.e. your writing/editing them) then you can declare dependencies following the PEP723 format and uv will respect that. https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
      • nomel 1y ago
        > uv run example.py I specifically want to run "python", rather subcommands for some other command, since I often I want to pass in arguments to the python interpreter itself, along with my script.
        • maleldil 1y ago
          You can use "uv run python script.py" to the same effect.
    • zbentley 1y ago
      Two options other than aliases: 1. Modify your PATH: export PATH="$(uv run python -BISc 'import sys; print(sys.base_exec_prefix)')/bin:$PATH" 2. Put this in an executable file called "python" early in your PATH: #!/bin/sh exec uv run python $* Those are basically what pyenv does (via a symlink and PATH entry). The second option will always pick up the Python local to the project directory you're in, if any. The former (if you put it in your shell profile) will not.
• neves 1y ago
  It is a venture capital startup. If I start use uv, what's our protection against the company going rogue?
  • xyst 1y ago
    Community will fork it and move on. See the following examples: * Redis -> redict, valkey * elastic search -> opensearch * terraform -> opentofu (Probably a few more but those are the ones that come to mind when they "go rogue")
    • neves 1y ago
      Does the current license allow it?
      • anderskaseorg 1y ago
        Yes, uv has a standard permissive open source license (Apache-2.0 OR MIT): https://github.com/astral-sh/uv/?tab=readme-ov-file#license https://github.com/astral-sh/uv/?tab=readme-ov-file#license
      • FergusArgyll 1y ago
        Apache & MIT - Yes
  • zffr 1y ago
    Why wouldn't you be able to switch back to using pip ?
    • nullhole 1y ago
      It seems like that'd work as long as you restrict yourself entirely to the pip interface. Stray outside of that, and you start accumulating a real dependency on uv itself.
      • maleldil 1y ago
• AJRF 1y ago
  Is there something inheret about rust that means its faster at dep resolution than Python? Like where is the speed up coming from? Or would it be possible to go this fast in python if you cared enough about speed? Is it a specific thing that rust has an amazing library for? Like Network or SerDe or something?
  • tcdent 1y ago
    They came up with a faster resolution algorithm, in addition to implementing it in a faster language. pip could be made faster based on this, but maybe not quite as fast.
    • _bent 1y ago
      The resolution algorithm is the pubgrub algorithm from Darts package manager pub, implemented in Rust for Cargo https://youtu.be/LGXx5Bqcgq8 https://youtu.be/LGXx5Bqcgq8
      • deleted 1y ago
        [deleted]
  • simonw 1y ago
    The biggest speed-up in uv comes from the way it uses caching and hard links. When you install a package into a virtual environment uv uses a hard link to a previously cached version rather than copying files. Using Rust is responsible for a lot of speed gains too, but I believe it's the hard linking trick (which could be implemented in any language) that's the biggest win.
    • aragilar 1y ago
      There's also the assumptions around wheels having consistent metadata (which isn't required in older versions of the specs), so as long as you don't need to support the long tail of packages, then those assumptions are fine (it's worth noting uv weren't the first to make these assumptions, poetry did this too, but pip does not).
• _lvbh 1y ago
  Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought. I now use uv for everything Python. The reason for the switch was a shared server where I did not have root and there were all sorts of broken packages/drivers and I needed pytorch. Nothing was working and pip was taking ages. Each user had 10GB of storage allocated and pip's cache was taking up a ton of space & not letting me change the location properly. Switched to uv and everything just worked If you're still holding out, really just spend 5 minutes trying it out, you won't regret it.
  • espdev 1y ago
    > Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought Really? :) requirements.txt is just hell and torture. If you've ever used modern project/dependency management tools like uv, Poetry, PDM, you'll never go back to pip+requirements.txt. It's crazy and a mess. uv is super fast and a great tool, but still has roughnesses and bugs.
    • pinoy420 1y ago
      [dead]
    • aequitas 1y ago
      Pip-tools+requirements.txt helped me survive the past few years. I also never thought I needed uv, but after all the talk about it I gave it a spin and never want back. It’s just so blazing fast en convenient.
    • _Algernon_ 1y ago
      pip also works with pyproject.toml. Sticking with requirements.txt is a self-imposed constraint.
    • kortex 1y ago
      We use uv to compile requirements.txt from pyproject.toml to get the locked versions. # Makefile compile-deps: uv pip compile pyproject.toml -o requirements.txt compile-deps-dev: uv pip compile --extra=dev pyproject.toml -o requirements.dev.txt
• jimjag 1y ago
  This has the same issue as so many package managers for Python, namely, it doesn't provide a way for --no-binary to remain sticky. There are times when you do NOT want the wheel version to be installed (which is what --no-binary implements in pip), but so many package managers including uv don't provide that core, basic functionality. At least for those that do use pip behind the scenes, like pipenv, one can still use the PIP_NO_BINARY environment variable to ensure this. So I'll not be migrating any time soon.
  • csl 1y ago
    Maybe not exactly what you need (sticky) but you can set UV_NO_BINARY=1 See https://docs.astral.sh/uv/reference/environment/#uv_no_binary https://docs.astral.sh/uv/reference/environment/#uv_no_binar...
    • jimjag 1y ago
      It helps, that's for sure. But this sort of knowledge should not exist in the environment in any case. It should be part of the canonical package list, and not hidden away elsewhere. The whole idea of a dependency manager should be a centralized and consistent way to install everything you need and not be dependent on what values may or may not exist as a env-var.
      • csl 1y ago
        Yes, I can see how it would make sense to be able to set this in pyproject.toml (typically for private package) uv is still quite new though. Perhaps you can open an issue and ask for that?
        • deleted 1y ago
          [deleted]
        • deleted 1y ago
          [deleted]
        • collinmanderson 1y ago
• shpx 1y ago
  For running scripts on my personal computer I really don't care for all the dependency management stuff. I just want a single, globally installed latest version of a library, like what pip does. I've never had the problem of an old script breaking, I guess because I just don't run that much software. These things for writing out explicit versions of everything and reinstalling libraries for every single project just add a lot of overhead, extra typing and an extra layer of complexity that I don't care for. I like just typing "pip install requests" and then being able to do "import requests" in any REPL or script for the next few years, occasionally running a Bash alias to upgrade all dependencies (which is a feature that pip incredibly still doesn't have, 14 years later). I can see how if you've had issues with dependencies you would rave about systems that let you control down to the commit what an import statement actually means, but I like the system that requires the least amount of typing/thinking and I imagine I'm part of a silent majority.
  • chuckadams 1y ago
    I've been out of the python world for a while now, but I would think a global install should just be a special case of a local install, one that's shared among scripts, which is basically how npm and yarn work. I'm kind of surprised uv doesn't support something like this already. Maybe it should be up to the distro to base the global python package management on uv then?
    • shpx 1y ago
      I think it does support it, like this uv pip install --system requests but it's more typing. If I type 5 characters per second, making me also type "uv --system" is the same as adding 2 seconds of runtime to the actual command, except even worse because the chance of a typo goes up and typing takes energy and concentration and is annoying.
      • chuckadams 1y ago
        If only there were a way to alias commands, eh?
  • 1y ago
• gamegod 1y ago
  Bragging that your program is faster than anything written in Python is a low bar, lol. Also, it seems like a sign that even Python tooling needs to not be written in Python now to get reasonable performance.
• mikevm 1y ago
  I think http://pixi.sh http://pixi.sh is much cooler because it supports conda environments so you can install non-python packages as well (e.g, gcc).
  • stere0 1y ago
    I was surprised to not see earlier laude for the amazing work at pixi.sh too. In our team we use both. UV is great when not dealing with any underlying dependencies. Pixi is our fallback if that fails.
    • mikevm 1y ago
      Where I work people work on shared Linux boxes so no one has root access. Conda environments are used to basically install packages you'd normally use a package manager for. Why do you use `uv` if `pixi` is a superset?
• spennant 1y ago
  I moved from pip to poetry a while back, but was introduced to uv recently while working on MCP stuff. I now use uv for everything and haven’t looked back.
  • decko 1y ago
    What made you switch from poetry?
• johncole 1y ago
  I love uv. I am a convert, I use it for everything. One area I find it incredible for: deployment. If I have to launch a docker container and install a lot of python packages it saves so much time and compute. I also appreciate that it handles most package conflicts and it constantly maintains the list of packages as you move. I have gotten myself into a hole or two now with packages and dependencies, I can usually solve it by deleting venv an just using uv to reinstall.
• nrvn 1y ago
  this is my new fav for running small executable scripts: #!/usr/bin/env -S uv --quiet run --script # /// script # requires-python = ">=3.13" # dependencies = [ # "python-dateutil", # ] # /// # # [python script that needs dateutil]
  • mdeeks 1y ago
    I really wish that hashbang line was something way WAY easier to remember like `#!/usr/bin/env uvx`. I have to look this up every single time I do it.
    • PufPufPuf 1y ago
      Sadly hashbangs are technically limited to: 1) Support only absolute paths, making it necessary to use /usr/bin/env which is in standardized location to look up the uv binary 2) Support only a single argument (everything after the space is passed as a single arg, it's not parsed into multiple args like a shell would), making it necessary to use -S to "S"plit the arguments. It's a feature of env itself, for this very use case. So there isn't really much to do to make it simpler.
      • mdeeks 1y ago
        I wasn't really referring to env. I meant change the behavior of uvx. If the first argument passed to uvx is a file path, then execute it exactly the same way as `uv --quiet run --script` does. Or maybe create a second binary or symlink called `uvs` (short for uv script) that does the same thing.
• renewiltord 1y ago
  The Astral projects are all great. I hope the company finds a revenue stream in the future with some hosted something or the other because these tools are so useful I don't want them to become pay-for etc.
• mixmastamyk 1y ago
  People always mention the speed, but that's rarely a factor for me. Rather, pip was broken intentionally two years ago and they are still not interested in fixing it: https://github.com/pypa/packaging/issues/774 https://github.com/pypa/packaging/issues/774 I tried uv and it just worked.
• octo888 1y ago
  uv has converted people in the same way Google search, Chrome, Git and SSDs did. Fast is a massive factor. I haven't used it much, but being so fast, I didn't even stop to think "is it perfect at dependency management?" "does it lack any features?".
  • stickfu 1y ago
    Ease of use was the key for me
• nchmy 1y ago
  I've been happily using it for a long time, and rye before that. Just today I set it up on 20 PCs in a computer lab that doesn't have internet, along with vs code and some main packages. Just downloaded the files, made a powershell script and it's all working great with Jupyter etc... Now to get kids to be interested in it...
• chuckhend 1y ago
  Very relevant talk if anyone is interested in learning a bit more about how the project is so fast. https://www.youtube.com/watch?v=gSKTfG1GXYQ https://www.youtube.com/watch?v=gSKTfG1GXYQ
  • stickfu 1y ago
    Never thought to see if Jane Street had a YouTube or if they had programming related stuff but here we are thanks to you! Makes sense they do, and that it’s python related.
• jhoechtl 1y ago
  Its sad that pyrhon only tooling is aparently so imcapable that you have to write it in a compiled language. After that many years of optimization pure python seems still to be wishfull thinking. It's ai/mk success is also only as a shim language around library calls.
  • globular-toast 1y ago
    So? It's the best language there is for shimming around library calls. Use the right tool for the job. There's no single language that can do it all.
• FL33TW00D 1y ago
  uv has completely changed the experience of Python for me.
• larkost 1y ago
  Just a warning in case others run into it: on very anemic systems (e.g.: AWS T2.micro running Windows, yes... I know...) uv will try to open too many simultaneous downloads, overloading things, resulting in timeouts. You can use ent ENV variable UV_CONCURRENT_DOWNLOADS to limit this. In my case it needed to be 1 or 2. Anything else would cause timeouts. An extreme case, I know, but I think that uv is too aggressive here (a download thread for every module). And should use aggregate speeds from each source server as a way of auto-tuning per-server threading.
  • choppaface 1y ago
    uv can also run even a beefy linux desktop out of file descriptors for larger projects. And does not have deterministic / reproducible installs. Still needs maturity.
  • ehsankia 1y ago
    Not extreme at all, A lot of people use the cheapest smallest VPS for their hobby work. I know I do (albeit not AWS). Thanks for sharing, hope they improve the automatic detection there.
• bunderbunder 1y ago
  uv is indeed fast and easy. But I'm also finding that the maintainers' efforts to make it work like Cargo mean it can be more difficult to use in more complex project structures. As sensible as Rust's project management ethos is, you're never going to escape Python's underlying design in a Python project, and friction between the two philosophies may not be avoidable. One possible alternative is Pants. It's also written in Rust for performance, but has more flexibility baked into the design.
  • kortex 1y ago
    Pants and uv are two very different tools, with very different use-cases. uv is basically souped-up pip. Pants is an entire build/tooling system, analogous to something like Bazel. It can handle multiple dependency trees, multiple types of source code, building and packaging, even running tests.
    • bunderbunder 1y ago
      uv is so much more than just a souped-up pip. It can also, for example, do building and packaging. It also has workspaces and subprojects features that are sneaking toward something like the full-fledged multi-artifact project support you get in Pants (or Poetry, with plugins). Except that their decision that the entire project must have one and only one global dependency solution means that there's no escape hatch if you ever end up in a dependency hell situation. Which is fairly common in Python for a variety of reasons. And, even when it does work, subprojects all sharing a single virtualenvironment means it's really easy to accidentally create an undeclared dependency and never notice at development time because it's already in the venv due to a sister project already having declared it. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive. That's a major reason why Python development culture decided to go with many project-specific virtualenvironments instead of a single global one like what uv is trying to drive toward. And it's true that it still allows you to do independent projects that reference each other at development time using path dependencies. But, unlike some of its more mature alternatives, it doesn't give you any help with replacing those path dependencies with named, version dependencies at build time. So if you have a project that builds multiple packages, you're on your own for implementing a solution to ensure packages with sane dependency specs get published to the archive.
• marifjeren 1y ago
  Seems a lot of people like this and are happy about it, but I for one am tired of the proliferation of python package management tools. Many languages have many package management tools but most languages there are one or two really popular ones. For python you just have to memorize this basically: - Does the project have a setup.py? if so, first run several other commands before you can run it. python -m venv .venv && source .venv/bin/activate && pip install -e . - else does it have a requirements.txt? if so python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt - else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run - else does it have a pipfile? pipenv install and then prefix all commands with pipenv run - else does it have an environment.yml? if so conda env create -f environment.yml and then look inside the file and conda activate <environment_name> - else I have not had to learn the rules for uv yet Thank goodness these days I just open up a cursor tab and say "get this project running"
  • kortex 1y ago
    uv handles most, if not all, of those cases. > - else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run That's not even correct. Not all projects with pyproject.toml use poetry (but poetry will handle everything with a pyproject.toml) Just try uv first. `uv pip install .` should work in a large majority of cases. pipenv is on the way out. bare `setup.py` is on the way out. `pyproject.toml` is the present and future, and the nice thing about it is it is self-describing in the tooling used to package.
    • marifjeren 1y ago
      > That's not even correct. Not all projects with pyproject.toml use poetry I didn't say "all projects with pyproject.toml use poetry"
    • eyegor 1y ago
      I wish setup.py was actually on the way out, but sadly, it's the only straightforward way to handle packages that use cython or interop. In these cases, libraries use setup.py to compile the dll/so/dylib at install time. Naturally this is a bit of nightmare fuel since installing gets arbitrary code execution privileges but there's no real standard for privileges in python package installs.
• deleted 1y ago
  [deleted]
• IceHegel 1y ago
  Biggest dev QoL improvement for me since TypeScript has been going all in on uv. I switched everything over and haven’t looked back. It’s everything I hoped poetry would be, but 10x less flakey.
• linsomniac 1y ago
  I'm setting up a new dev workstation and I'm trying NixOS and for Python work I'm going to try living with "uv" for the bulk of my Python work. An experiment I've just started, but I've been using uv for ~6 months and it's been spectacular and I think it's going to be able to live up to my expectations.
• aanet 1y ago
  Now.. can they make Python itself as fast as the package manager??
• zero-g 1y ago
  What’s their motivation to build tools like uv and ruff? What’s their business model?
  • joshdavham 1y ago
    They’re still figuring it out and I believe that they’re also still pre-revenue. With that being said, if you’re able to capture a large part of the python ecosystem, I imagine business ideas won’t be too hard to come by!
    • collinmanderson 1y ago
      See also this comment which has more information from an interview with their founder. https://news.ycombinator.com/item?id=44358482 https://news.ycombinator.com/item?id=44358482
      • joshdavham 1y ago
        A private package registry is a pretty exciting idea! I honestly wouldn't have expected that idea from them. If they do pursue that idea, I wonder if they'd also have a public component to it that could act as a better PyPI?
• andy_ppp 1y ago
  I have no understanding of python really but very glad I settled on uv. It’s such an improvement user wise over poetry or pip and it’s extremely fast too. I have one complaint though, I want ./src to be the root of my python packages such that > from models.attention import Attention Works if I have a directory called models with a file called attention.py in it (and __init__.py) etc. The only way this seems to work correctly is if I set PYTHONPATH=./src Surely the environment manager could set this up for me? Am I just doing it wrong?
  • andy_ppp 1y ago
    ChatGPT says two things to this “uv is a package manager not a file runner” um uv run seems to be one of the best parts of uv… and that “You’re doing things correctly you are just hitting one of Python’s most notorious pain points: managing import paths cleanly”. I have read a few tickets saying uv won’t support this so everyone running my project will have to read the README first to get anything to run. Terrible UX.
    • bilbo-b-baggins 1y ago
      What is it that uv won’t support?
      • andy_ppp 1y ago
        Setting PYTHONPATH (or for that matter any other Env vars) by default. Seems useful to me.
  • collinmanderson 1y ago
    src layout _should_ work. The pyproject.toml needs to live next to src, not inside of it. You might need to `uv run python` in order to pick up the right PYTHONPATH? https://docs.astral.sh/uv/concepts/projects/init/#packaged-applications https://docs.astral.sh/uv/concepts/projects/init/#packaged-a... uv init --package example-pkg cd example-pkg uv run python >>> from example_pkg import main
• kissgyorgy 1y ago
  Astral's tools are so fast in general, when you first try them out, you double check what went wrong because you are sure nothing happened. Same with uv. They are doing very nice tricks, like sending Range requests to only download the metadata part from the ZIP file from PyPI, resolve them in memory and only after that downloading the packages. No other package manager does this kind of crazy optimization.
• samsartor 1y ago
  I'm in ML-land. I thought we were all hopelessly tied to conda. But I moved all my own projects to uv effortlesly and have never looked back. Now first thing I do when pulling down another reseacher's code is add a pyproject toml (if they don't have one), `uv add -r`, and `uv run` off into the sunset. I especially like how good uv is with non-pypi-published dependencies: GitHub, dumb folders, internal repos, etc.
• singularity2001 1y ago
  wake me when venv works on mac
  • gyrovagueGeist 1y ago
    It does? What problems have you had?
    • singularity2001 1y ago
      source .venv/bin/activate .venv/bin/activate:37: parse error near `deactivate' Automatically generated, not compatible with zsh
      • gyrovagueGeist 1y ago
        I can't reproduce this, possibly it's another environment error or the problem has been fixed in the versions I am using. (uv 0.7.11, zsh 5.9, python 3.13.5, MacOS 15.3.1)
• jauntywundrkind 1y ago
  I ran into this via Aider. Who centers their user experience on using uv as an installer. https://aider.chat/2025/01/15/uv.html https://aider.chat/2025/01/15/uv.html What was super unclear was how I develop locally with uv. Figuring out I needed `aider sync --extra` then `aider run --projrct /opt/aider aider` to run was a lot of bumbling in the dark. I still struggle to find good references for everyday running projects use with uv. It was amazing though. There were so many pyproject and other concerns that it just knew how to do. I kept assuming I was going to have to do a lot more steps.
• tfarias 1y ago
  I switched to uv in an open source project I maintain as our builds were taking dozens of minutes to resolve dependencies using Poetry. The migration itself was pretty easy as both tools use pyproject.toml, so it was a matter of changing headers and minor adjustments. After the switch, the same dependency resolution was done in seconds. This tool single-handedly made iteration possible again.
• GardenLetter27 1y ago
  The only thing keeping Python usable.
• codethief 1y ago
  uv is great! One surprise I recently ran into, though, was that `uv run path/to/foo.py` doesn't look up the nearest pyproject.toml / .venv. Similarly, a script with a shebang `#!/usr/bin/env -S uv run` only executes correctly when executed from within the folder containing the .venv. Am I the only one finding this weird?
  • bilbo-b-baggins 1y ago
    I think the thought is to be obviously deterministic. It’s not exactly trivial to make those decisions for users since uv is not locked to its .venv - you may want the env, the system python, a pyenv, a brew python, or whatever variation can co-exist seamlessly. I’d be surprised if there wasn’t an env var for it though.
• spapas82 1y ago
  I don't use uv for my (django) projects because my pip/venv workflow is good enough and had never failed me in 15 years. However I really like installing uv globally on my Windows systems and then using uvx to run stuff without caring about venvs and putting stuff to path.
• esafak 1y ago
  It's not just the programs that are fast, but the company's response. I reported an issue on Discord and the founder fixed it right away, collaborating with me on the PR I created.
• joshdavham 1y ago
  I still mostly use pip (largely due to habit) but uv has been incredible for speeding up ci workflows! We shaved off a full minute of CI for a python package I maintain when we started using uv.
• richard___ 1y ago
  Why use this over micromamba?
  • y1zhou 1y ago
    I use the two together with no issues. Micromamba works great for conda dependencies that’s not on PyPi (for many reasons), and everything else I go for uv.
• insane_dreamer 1y ago
  uv is great and we have largely switched over to using it. however, since it doesn't handle compiled binaries, we have to continue using conda for environments where those are needed (i.e., mkl).
• holografix 1y ago
  Can anyone point to the top 3 Rust specific things that UV leverages to make it run so much faster? Yes I know Rust is not a GC language… go a level deeper
  • yoyohello13 1y ago
    There is nothing Rust specific as far as I’m aware, other than the developers are comfortable with the language. They have a very fast dependency resolver/algo, but presumably you could implement that in C or Zig or whatever. It is much faster than if it was implemented in Python or another interpreted language though. Ruff is way, way faster than the equivalent Python tools. I like Rust for the type safety and tooling so that may slow them to build faster?
  • quantisan 1y ago
    1. Zero-Copy Deserialization with rkyv and Unsafe Code 2. Platform-Specific High-Performance Memory Allocators 3. High-Performance Hash Maps with FxHasher and SwissTable https://deepwiki.com/search/point-to-the-top-3-rust-specif_456fe54f-ea36-4a71-8a07-25a14f63c2f1 https://deepwiki.com/search/point-to-the-top-3-rust-specif_4...
• nickjj 1y ago
  If anyone is looking for examples on using uv with Docker, I have Flask and Django example apps at https://github.com/nickjj/docker-flask-example https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example. It prevents uv from making a virtual environment and does some optimizations like compiling byte code once when your dependencies get installed. It was well worth the switch. I noticed a ~10x improvement for speed compared to pip (30s to 3s to install all dependencies). Proper lock file support is nice too. Funny enough I wrote about and made a video about switching to uv about a week ago here https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dockerized-flask-or-django-app https://nickjanetakis.com/blog/switching-pip-to-uv-in-a-dock....
• cagr 1y ago
  was forced to use it for work and was converted!
• talles 1y ago
  Why the "written in Rust" in the title?
  • stackedinserter 1y ago
    It's +5hp, like these two white stripes on a car hood.
• heohk 1y ago
  uvx is the killer app imo
• curtisszmania 1y ago
  [dead]
• a_t48 1y ago
  I've started on a CMake integration to take multiple pyproject.toml files (in a monorepo or such), turn them into an editable workspace venv for development (with dependencies), and then on `make install` package the workspace up into a venv (at some point I'll add a package target...). The lock file ends up checked in and updated whenever you build w/ changes to any of the pyproject files. This is very very useful for robotics or other places where you might end up with a big list of pip installed packages in some Dockerfile, want them pinned, with just one version of each library across the whole space, but don't want to necessarily do the song and dance of a full python package. Because uv is fast it just kind of works and checking the projects doesn't take any time at all compared to the other build work being done.
• bicepjai 1y ago
  Started out with conda mainly because it played nicely with jupyter, but after switching to fish and vscode on mac, managing conda environments for Jupyter kernels turned into a pain. Honestly, half my personal projects procrastination comes down to fighting with conda setup. Been hearing a lot of buzz about UV, and this post finally convinced me to give it a shot on my next project. Sources
• rakel_rakel 1y ago
  uv is so good, I would recommend it to anyone. The suffix "written in Rust" is getting cringy though.
• aaronbrethorst 1y ago
  I'm looking forward to adopting uv but I'm blocked until Snyk supports it. https://support.snyk.io/s/question/0D5PU00000u1G4n0AE/support-for-uv-as-a-package-manager-for-python https://support.snyk.io/s/question/0D5PU00000u1G4n0AE/suppor...
  • rienbdj 1y ago
    Export a requirements.txt from UV and analyze that?
• jaza 1y ago
  Switched all my python stuff to poetry several years ago. Still kinda tired and shagged out from that endeavour. Yeah yeah, ok ok, if y'all keep raving THIS much about uv, I guess it must be pretty good ... still, sigh, yet another One True (tm) python package management solution. It's on my todo list, I'll get around to it, I reckon within the next 12 months, currently I have no pressing need to move away from poetry.
  • collinmanderson 1y ago
    You don't know what you're missing if you haven't spent 5 minutes trying out uv. If you're intentionally not trying it simply because you don't want to get addicted like everyone else clearly is, I could see that as a valid reason to never try it in the first place. I usually avoid jumping on bandwagons, so I've always stuck with vanilla pip/venv, but at this point it really is clear to me that uv really is the "One True (tm) python package management solution", and probably will be for the next 10 years.
• helsinki 1y ago
  I’ve been writing an equivalent of uv for the R language at work, and it’s quite daunting / unwieldy. I was feeling bad about it, but then I reminded myself that uv has hundreds of contributors and my project only has one.
• bandrami 1y ago
  I was just thinking the dearth of package managers for Python is such a missed opportunity
• insane_dreamer 1y ago
  Relevant: https://sgoel.dev/posts/building-cython-or-c-extensions-using-uv/ https://sgoel.dev/posts/building-cython-or-c-extensions-usin...
• bbd108 1y ago
  One of may favorite party tricks with uv: echo 'import antigravity' | uv run - Thank you astral!
• skanga 1y ago
  https://github.com/skanga/JarGet https://github.com/skanga/JarGet is a slightly similar tool for Java
• laurent_du 1y ago
  Yes `uv` is great but using it to manage dependencies in an AWS Lambda Docker container is really not as simple as using pip or poetry.
• kat529770 1y ago
  [dead]
• v5v3 1y ago
  For MacOS the install doesnt mention if on homebrew?
  • lucky_cloud 1y ago
    You can `brew install uv`
• seatac76 1y ago
  I’ve been writing Python for over a decade and was still using the Pyenv Virtualenv (dated I know). Lately I had been trying to switch over to Poetry. Somehow it never works smoothly for me. Then I looked at uv and oh boy is it better. Everything just works and is blazing fast. Kudos to the team.