31 ms·

Uv is the best thing to happen to the Python ecosystem in a decade

• NewJazz 1y ago
  Idk, for me ruff was more of a game changer. No more explaining why we need both flake8 and pylint (and isort), no more flake8 plugins... Just one command that does it all. UV is great but I use it as a more convenient pip+venv. Maybe I'm not using it to it's full potential.
  • zahlman 1y ago
    > Maybe I'm not using it to it's full potential. You aren't, but that's fine. Everyone has their own idea about how tooling should work and come together, and I happen to be in your camp (from what I can tell). I actively don't want an all-in-one tool to do "project management".
  • hirako2000 1y ago
    The dependencies descriptor is further structured, a requirements.txt is pretty raw in comparison. But where it isn't a matter of opinion is, speed. Never met anyone who given then same interface, would prefer a process taking 10x longer to execute.
  • collinmanderson 1y ago
    I agree flake8 -> ruff was more of a game changer for me than pip+venv -> uv. I use flake8/ruff for more often than pip/venv. uv is probably much more of a game changer for beginner python users who just need to install stuff and don't need to lint. So it's a bigger deal for the broader python ecosystem.
• languagehacker 1y ago
  A very accessible and gentle introduction for the scientific set who may still be largely stuck on Conda. I liked it!
  • sanskarix 1y ago
    This resonates so much. As someone who's more on the builder/product side than engineering, I've always felt that barrier with Python tooling. The learning curve for environment management has been one of those silent productivity killers. What strikes me about uv is that it seems to understand that not everyone launching a Python-based project has a CS degree. That accessibility matters—especially in the era where more non-engineers are building products. Curious: for those who've switched to uv, did you notice any friction when collaborating with team members who were still on traditional setups? I'm thinking about adoption challenges when you're not a solo builder.
• Animats 1y ago
  Another Python package manager? How many are there now?
  • zahlman 1y ago
    > Another No, the same uv that people have been regularly (https://hn.algolia.com/?q=uv https://hn.algolia.com/?q=uv) posting about on HN since its first public releases in February of 2024 (see e.g. https://news.ycombinator.com/item?id=39387641 https://news.ycombinator.com/item?id=39387641). > How many are there now? Why is this a problem? The ecosystem has developed usable interoperable standards (for example, fundamentally uv manages isolated environments by using the same kind of virtual environment created by the standard library — because that's the only kind that Python cares about; the key component is the `pyvenv.cfg` file, and Python is hard-coded to look for and use that); and you don't have to learn or use more than one. There are competing options because people have different ideas about what a "package manager" should or shouldn't be responsible for, and about the expectations for those tasks.
    • andy99 1y ago
      It’s definitely an issue for learning the language. Obviously after working with python a bit that doesn’t matter, but fragmentation still makes it more of a hassle to get open source projects up and running if they don’t use something close to your usual package management approach.
• andrewstuart 1y ago
  Venv seems pretty straightforward once you’ve learned the one activate command. I don’t really get that uv solves all these problems ve never encountered. Just make a venv and use it seems to work fine.
  • athorax 1y ago
    For me the biggest value of uv was replacing pyenv for managing multiple versions of python. So uv replaced pyenv+pyenv-virtualenv+pip
    • Hasz 1y ago
      This is it. Later versions of python .11/.12/.13 have significant improvements and differences. Being able to seamlessly test/switch between them is a big QOL improvement. I don't love that UV is basically tied to a for profit company, Astral. I think such core tooling should be tied to the PSF, but that's a minor point. It's partially the issue I have with Conda too.
      • rkomorn 1y ago
        Didn't Astral get created out of uv (and other tools), though? Isn't it fair for the creators to try and turn it into a sustainable job? Edit: or was it ruff? Either way. I thought they created the tools first, then the company.
      • zahlman 1y ago
        > Later versions of python .11/.12/.13 have significant improvements and differences. Being able to seamlessly test/switch between them is a big QOL improvement. I just... build from source and make virtual environments based off them as necessary. Although I don't really understand why you'd want to keep older patch versions around. (The Windows installers don't even accommodate that, IIRC.) And I can't say I've noticed any of those "significant improvements and differences" between patch versions ever mattering to my own projects. > I don't love that UV is basically tied to a for profit company, Astral. I think such core tooling should be tied to the PSF, but that's a minor point. It's partially the issue I have with Conda too. In my book, the less under the PSF's control, the better. The meager funding they do receive now is mostly directed towards making PyCon happen (the main one; others like PyCon Africa get a pittance) and to certain grants, and to a short list of paid staff who are generally speaking board members and other decision makers and not the people actually developing Python. Even without considering "politics" (cf. the latest news turning down a grant for ideological reasons) I consider this gross mismanagement.
• mgh95 1y ago
  As someone who generally prefers not to use python in a production context (I think it's excellent for one-off scripts or cron jobs that require more features then what bash provides), I agree with this sentiment. I recently wrote some python (using uv) and found it to be pleasant and well-integrated with a variety of LSPs.
  • deleted 1y ago
    [deleted]
• curiousgal 1y ago
  The best thing to happen to the Python ecosystem would be something that unites pip and conda. Conda is not going anywhere given how many packages depend on non-python binaries, especially in enterprise settings.
  • zahlman 1y ago
    The standard approach nowadays is to vendor the binaries, as e.g. Numpy does. This works just fine with pip. I'm interested if you have any technical documentation about how conda environments are structured. It would be nice to be able to interact with them. But I suspect the main problem is that if you use a non-conda tool to put something into a conda environment, there needs to be a way to make conda properly aware of the change. Fundamentally it's the same issue as with trying to use pip in the system environment on Linux, which will interfere with the system package manager (leading to the PEP 668 protections).
  • karlding 1y ago
    I'm not sure if you're aware, but there's the Wheel Variants proposal [0] that the WheelNext initiative is working through that was presented at PyCon 2025 [1][2], which hopes to solve some of those problems. uv has implemented experimental support, which they announced here [3]. [0] https://wheelnext.dev/proposals/pepxxx_wheel_variant_support/ https://wheelnext.dev/proposals/pepxxx_wheel_variant_support... [1] https://us.pycon.org/2025/schedule/presentation/100/ https://us.pycon.org/2025/schedule/presentation/100/ [2] https://www.youtube.com/watch?v=1Oki8vAWb1Q https://www.youtube.com/watch?v=1Oki8vAWb1Q [3] https://astral.sh/blog/wheel-variants https://astral.sh/blog/wheel-variants
  • dugidugout 1y ago
    I had this discussion briefly with a buddy who uses python exclusively for his career in austronomy. He was lamenting the pains of colaborting around Conda and seemed convinced it was irreplaceable. Being that I'm not familiar with the exact limitations Conda is providing for, Im curious if you could shed some insight here. Does nix not technically solve the issue? I understand this isn't solely a technical problem and Nix adoption in this space isn't likely, but I'm curious none-the-less!
  • 1y ago
• verdverm 1y ago
  I'd put type annotations and GIL removal above UV without a second thought. UV is still young and I hit some of those growing pains. While it is very nice, I'm not going to put it up there with sliced bread, it's just another package manager among many
  • WD-42 1y ago
    As far as impact on the ecosystem I’d say uv is up there. For the language itself you are right. Curious if you’ve come across any real use cases for Gil-less python. I haven’t yet. Seems like everything that would benefit from it is already written in highly optimized native modules.
    • seabrookmx 1y ago
      > Seems like everything that would benefit from it is already written in highly optimized native modules Or by asyncio.
      • WD-42 1y ago
        I'm pretty ignorant about this stuff but I think asyncio is for exactly that, asynchronus I/O. Whereas GIL-less Python would be beneficial for CPU bound programs. My day job is boring so I'm never CPU bound, always IO bound on the database or network. If there is CPU heavy code, it's in Numpy. So I'm not sure if Gil-less actually helps there.
      • nomel 1y ago
        asyncio is unrelated to the parallelism prevented by the GIL.
    • rustystump 1y ago
      I second and third this. I HATE python but uv was what made it usable to me. No other language had such a confusing obnoxious setup to do anything with outside of js land. uv made it sane for me.
      • 1y ago
• hollow-moe 1y ago
  curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I'm against closed computers but I'm also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.
  • 01HNNWZ0MV43FF 1y ago
    Maybe there will be a .deb one day
    • mystifyingpoi 1y ago
      That doesn't fix the core issue. You can put anything inside a .deb file, even preinstall script can send your ~/.aws/credentials to China. The core concern is getting a package that's verified by a volunteer human to not contain anything malicious, and then getting that package into Debian repository or equivalent.
  • chasd00 1y ago
    can't you just do curl|more and then view what it's going to do? Then, once you're convinced, go back to curl|sh. /just guessing, haven't tried it
    • threeducks 1y ago
      A malicious server could detect whether the user is actually running "curl | sh" instead of just "curl" and only serve a malicious shell script when the code is executed blindly. See this thread for reference: https://news.ycombinator.com/item?id=17636032 https://news.ycombinator.com/item?id=17636032
      • chasd00 1y ago
        well you still have to execute the shell script at some point. You could do curl > install.sh, open it up to inspect, and then run the install script which would still trigger the callback to the server mentioned in the link you posted. I guess it's really up to the user to decide what programs to run and not run.
• dark__paladin 1y ago
  Genuinely trying to learn here - what's the major advantage of using uv over conda? (Transparently, I'm posting this before I've completed the article.)
  • collinmanderson 1y ago
    uv is unbelievably fast.
    • zahlman 1y ago
      The speed is quite believable. Reinstalling packages from a cache should be extremely fast. Pip suffers from poor architecture.
  • ethmarks 1y ago
    They have different use cases. uv is meant to be the singular tool for managing Python packages and dependencies, replacing pip, virtualenv, and pip-tools. Conda is for more general-purpose environment management, not just Python. If you're doing something with Node or R, uv won't work at all because it's only for Python. uv's biggest advantage is speed. It claims a 10-100x performance speedup over pip and Conda [1]. uv can also manage python versions and supports using Python scripts as executables via inline dependencies [2]. But Conda is better for non-Python usage and is more mature, especially for data science related uses. [1]: https://github.com/astral-sh/uv/blob/main/BENCHMARKS.md https://github.com/astral-sh/uv/blob/main/BENCHMARKS.md [2]: https://docs.astral.sh/uv/#scripts https://docs.astral.sh/uv/#scripts
• LeoPanthera 1y ago
  For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.
  • d4mi3n 1y ago
    If I were to put on my security hat, things like this give me shivers. It's one thing if you control the script and specified the dependencies. For any other use-case, you're trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent. This isn't a knock against UV, but more a criticism of dynamic dependency resolution. I'd feel much better about this if UV had a way to whitelist specific dependencies/dependency versions.
    • chatmasta 1y ago
      If you’re executing a script from an untrusted source, you should be examining it anyway. If it fails to execute because you haven’t installed the correct dependencies, that’s an inconvenience, not a lucky security benefit. You can write a reverse shell in Python with no dependencies and just a few lines of code.
      • 1oooqooq 1y ago
        it's a stretch to "executing a script with a build user" or "from a validated distro immutable package" to "allowing something to download evergreen code and install files everywhere on the system".
        • teruakohatu 1y ago
          A vanilla python can write files, edit ~/.zsh to create an sudo alias that executes code next time you invoke sudo and type in your password. uv installing deps is hardly more risky.
• runningmike 1y ago
  Seems like a commercial blog. And imho hatch is better from a Foss perspective. UV means getting more strings attached with VC funded companies and leaning on their infrastructure. This is a high risk for any FOSS community and history tells us how this ends….
  • maccard 1y ago
    You say this on a message board run by a VC about a programming language that is primarily developed by meta, google and co. uv is MIT licensed so if they rug pull, you can fork.
    • LtWorf 1y ago
      It's still annoying to fork and they will probably try to move it to their own pypi service so it won't be possible to do that.
      • maccard 1y ago
        I’d rather use a great tool for a year and a half (which I have done) and suffer the pain of a fork once than have to use a worse tool. Look at terraform and the tofu fork - it took a while but throughout the peocsss you could just stick to the last open source version of terraform until you decided what you wanted to do. Ironically the fork there is now controlled by the VC backed firms people love to decry
  • robot-wrangler 1y ago
    This is going to sound harsh, but the problem with hatch is that it's pypa. And look at all the people that equate python-the-language with problems in pypa-managed solutions already. Pypa does not make good stuff or make good decisions. Speaking of history, I was very sympathetic to the "we are open-source volunteers, give us a break" kind of stuff for the first N years.. but pypa has a pattern of creating problems, ignoring them, ignoring criticism, ignoring people who are trying to help, and pushing talent+interest elsewhere. This has fragmented the packaging ecosystem in a way that confuses newcomers, forces constant maintenance and training burden on experts, and damages the credibility of the language and its users. Hatch is frankly too little too late, and even if it becomes a wonderful standard, it would just force more maintenance, more confusion for a "temporary" period that lasts many, many years. Confidence is too far gone. As mentioned elsewhere in the thread, there are tons of conflicting tools in the space already, and due to the fragmentation, poetry etc could never get critical mass. That's partly because pypa stuff felt most "official" and a safer long term bet than anything else, but partly because 33% better was never good enough to encourage widespread adoption until it was closer to 200% better. But uv actually IS that much better. Just let it win. And let pypa be a case-study in how to NOT do FOSS. Fragmentation is fine up to a point, but you know what? If it wasn't for KDE / Gnome reinventing the wheel for every single kind of individual GUI then we'd have already seen the glorious "year of the linux desktop" by now.
• kyt 1y ago
  I must be the odd man out but I am not a fan of uv. 1. It tries to do too many things. Please just do one thing and do it well. It's simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command. 2. You end up needing to use `uv pip` so it's not even a full replacement for pip. 3. It does not play well with Docker. 4. It adds more complexity. You end up needing to understand all of these new environmental variables: `UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.
  • defraudbah 1y ago
    yeah, I've moved away from it too, but that's a great tool. A rush of rust tools is the best thing that happened to python in the decade
  • leblancfg 1y ago
    uv's pip interface is like dipping one toe in the bathtub. Take a minute and try on the full managed interface instead: https://docs.astral.sh/uv/concepts/projects/dependencies https://docs.astral.sh/uv/concepts/projects/dependencies. Your commands then become: - uv add <package_name> - uv sync - uv run <command> Feels very ergonomic, I don't need to think much, and it's so much faster.
  • daedrdev 1y ago
    I mean I’ve had quite awful bugs from using pip pyenv and venv at the same time
  • chatmasta 1y ago
    What problems do you encounter using it with Docker?
  • xmprt 1y ago
    Your implication is that pyenv, virtualenv, and pip should be 3 different tools. But for the average developer, these tools are all related to managing the python environment and versions which in my head sounds like one thing. Other languages don't have 3 different tools for this. pip and virtualenv also add a ton of complexity and when they break (which happens quite often) debugging it is even harder despite them being "battle tested" tools.
• aerhardt 1y ago
  I'm surprised by how much I prefer prepending "uv" to everything instead of activating environments - which is still naturally an option if that's what floats your boat. I also like how you can manage Python versions very easily with it. Everything feels very "batteries-included" and yet local to the project. I still haven't used it long enough to tell whether it avoids the inevitable bi-yearly "debug a Python environment day" but it's shown enough promise to adopt it as a standard in all my new projects.
  • bobsomers 1y ago
    Personally, I prefer prepending `uv` to my commands because they're more stateless that way. I don't need to remember which terminal my environment is sourced in, and when copying and pasting commands to people I don't need to worry about what state their terminal is it. It just works.
  • zahlman 1y ago
    > how much I prefer prepending "uv" to everything instead of activating environments You can also prepend the path to the virtual environment's bin/ (or Scripts/ on Windows). Literally all that "activating an environment" does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means modifying $PS1) as a reminder, and sets up whatever's necessary to undo the changes (on my system that means defining a "deactivate" function; others may have a separate explicit script for that). I personally don't like the automatic detection of venvs, or the pressure to put them in a specific place relative to the project root. > I also like how you can manage Python versions very easily with it. I still don't understand why people value this so highly, but so it goes. > the inevitable bi-yearly "debug a Python environment day" If you're getting this because you have venvs based off the system Python and you upgrade the system Python, then no, uv can't do anything about that. Venvs aren't really designed to be relocated or to have their underlying Python modified. But uv will make it much faster to re-create the environment, and most likely that will be the practical solution for you.
    • lelandbatey 1y ago
• atonse 1y ago
  These rust based tools really change the idea of what's possible (when you can get feedback in milliseconds). But I'm trying to figure out what Astral as a company does for revenue. I don't see any paid products on their website. They even have investors. So far it seems like they have a bunch of these high performance tools. Is this part of an upcoming product suite for python or something? Just curious. I'm not a full-time python developer.
  • deleted 1y ago
    [deleted]
  • tabletcorry 1y ago
    Take a look at their upcoming product Pyx to see where revenue can start to come in for paid/hosted services. https://astral.sh/pyx https://astral.sh/pyx
  • deleted 1y ago
    [deleted]
  • bruckie 1y ago
    From "So how does Astral plan to make money? " (https://news.ycombinator.com/item?id=44358216 https://news.ycombinator.com/item?id=44358216): "What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. An example of what this might look like [...] would be something like an enterprise-focused private package registry." There's also this interview with Charlie Marsh (Astral founder): https://timclicks.dev/podcast/supercharging-python-tooling-an-interview-with-charlie-marsh https://timclicks.dev/podcast/supercharging-python-tooling-a... (specifically the "Building a commerical company with venture capital " section)
    • throwway120385 1y ago
      That doesn't really seem like a way to avoid getting "Broadcommed." Vertically integrated tooling is kind of a commodity.
    • 1y ago
• seabrookmx 1y ago
  Can't agree more. We were using pyenv+poetry before and regularly had to pin our poetry version to a specific one, because new poetry releases would stall trying to resolve dependencies. pyenv was problematic because you needed the right concoction of system packages to ensure it compiled python with the right features, and we have a mix of MacOS and Linux devs so this was often non-trivial. uv is much faster than both of these tools, has a more ergonomic CLI, and solves both of the issues I just mentioned. I'm hoping astral's type checker is suitably good once released, because we're on mypy right now and it's a constant source of frustration (slow and buggy).
  • kardos 1y ago
    > because new poetry releases would stall trying to resolve dependencies. > uv is much faster than both of these tools conda is also (in)famous for being slow at this, although the new mamba solver is much faster. What does uv do in order to resolve dependencies much faster?
    • collinmanderson 1y ago
      > What does uv do in order to resolve dependencies much faster? - Representing version numbers as single integer for fast comparison. - Being implemented in rust rather than Python (compared to Poetry) - Parallel downloads - Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.
• asaddhamani 1y ago
  I find the python tooling so confusing now. There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing. I like node, npm isolates by default, npx is easy to understand, and the ecosystem is much less fragmented. I see a python app on GitHub and they’re all listing different package management tools. Reminds me of that competing standards xkcd.
  • tabletcorry 1y ago
    Node has at least bun, and probably other tools, that attempt to speed things up in similar ways. New tooling is always coming for our languages of choice, even if we aren't paying attention.
  • theultdev 1y ago
    well there's npm, pnpm, yarn, bun package managers not a python developer, so not sure it's equivalent as the npm registry is shared between all.
  • collinmanderson 1y ago
    > There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing... > Reminds me of that competing standards xkcd. Yes, for years I've sat on the sidelines avoiding the fragmented Poetry, ppyenv, pipenv, pipx, pip-tools/pip-compile, rye, etc, but uv does now finally seem to be the all-in-one solution that seems to be succeeding where other tools have failed.
  • zahlman 1y ago
    > I see a python app on GitHub and they’re all listing different package management tools. In general, you can use your preferred package management tool with their code. The developers are just showing you their own workflow, typically.
• sdairs 1y ago
  Everything from the astral team has been superb, I don't want to use Python without ruff & uv. Yet to try "ty", anyone used it?
  • tabletcorry 1y ago
    Ty is still under very active development, so it either works or very much doesn't. I run it occasionally to see if it works on my codebases, and while it is getting closer, it isn't quite there yet. Definitely lightyears faster than mypy though.
  • collinmanderson 1y ago
    I'm waiting for ty to get TypedDict checking. https://github.com/astral-sh/ty/issues/154 https://github.com/astral-sh/ty/issues/154
• sph 1y ago
  There is something hilarious about using a project/package manager written in another language.
  • philipallstar 1y ago
    Wait til you find out what CPython is written in.
  • wiseowise 1y ago
    Care to share with the group what’s so hilarious?
• srameshc 1y ago
  I am still learning and I have the same feeling as someone who don't consider myself good with python. At least I can keep my venv in control now is all I can feel with Uv approach.
• dec0dedab0de 1y ago
  I don't like that it defaults to putting the virtual environment right there, I much prefer how pipenv does it with a shared one in the users home directory, but it's a small price to pay for how fast it is.
• dekhn 1y ago
  I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly. My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can't reproduce anything because just touching an env breaks the world.
  • gostsamo 1y ago
    As far as I get it, conda is still around because uv is focused on python while conda handles things written in other languages. Unless uv gets much more universal than expected, conda is here to stay.
    • tempay 1y ago
      There is also pixi (which uses uv for the python side of things) which feels like uv for conda.
      • okanat 1y ago
        Pixi is great! It doesn't purely use uv though. I just love it. It solves "creating a repo that runs natively on any developer's PC natively" problem quite well. It handles different dependency trees per OS for the same library too!
    • prpl 1y ago
      conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything. Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.
      • levocardia 1y ago
        Except the ONE annoying quirk that certain major projects and repos let their conda distribution get stale.
• throwaway091025 1y ago
  [flagged]
  • mttjj 1y ago
    Your point being? EDIT: Looks like I fell hook, line, and sinker for the troll. Shame on me.
    • throwaway091025 1y ago
      [flagged]
      • nilamo 1y ago
        > no point in trusting people who are disconnect from reality My brother in christ, we are all just names without bodies or even faces on this digital ocean of the internet. Letting people know how they should address you isn't "disconnected from reality", it's grounded in the very real reality that we, as people, like talking to each other. We should all be so thankful for their foresight in allowing us the opportunity of avoiding an otherwise unavoidable faux pas of calling everyone in the world "hey you".
  • nilamo 1y ago
    woah no way, dude. cool
• zem 1y ago
  I think ruff is the best thing to happen to the python ecosystem in a decade, it really sold the entire community on the difference fast native tooling could make.
• pixelpoet 1y ago
  Wait until they fully embrace the benefits of strong typing :)
• psunavy03 1y ago
  I have one problem with uv as of now, and it's more of an annoyance. It doesn't seem to understand the concept of >= when it's trying to resolve a local wheel I built and use. If I have 6.4.1 published on GitLab and the pyproject says $WHEEL_NAME>=6.2.0, it still goes to look for 6.2.0 (which I deleted) and errors out.
• hglaser 1y ago
  Am I the only one who feels like this is obviated by Docker? uv is a clear improvement over pip and venv, for sure. But I do everything in dev containers these days. Very few things get to install on my laptop itself outside a container. I've gotten so used to this that tools that uninstall/install packages on my box on the fly give me the heebie-jeebies.
  • collinmanderson 1y ago
    uv can be used to speed up building containers.
  • czbond 1y ago
    > I do everything in dev containers these days. Very few things get to install on my laptop itself outside a container. Yes, it was the NPM supply chain issues that really forced this one me. Now I install, fetch, build in an interactive Docker container
  • zahlman 1y ago
    Lots of people are doing things where they would prefer not to invoke the weight of an entire container.
  • NumberCruncher 1y ago
    > Am I the only one who feels like this is obviated by Docker? This whole discussion has the same vibes like digital photography 15 years ago. Back then some people spent more time on discussing the tech spec their cameras than takin photos. Now some people spend more time on discussing the pros and cons of different Python environment management solutions than building real things. The last time I had to touch one of my dockerized environments was when Miniconda and Miniforge were merged. I said the agent "fix the dockerfile", and the third attempt worked. Another time, one dependency was updated and I had to switch to Poetry. Once again, I said the agent "refactor the repository to Poetry" and it worked. Maybe because all my Python package versions are frozen and I only update them when they break or when I need the functionality of the new version. Whenever this topic pops up in real life, I always ask back what was the longest time they managed the same Python service in the cloud. In the most cases, the answer is never. The last time someone said one year. After a while this service was turned into two .py files. I don't know. Maybe I'm just too far away from FAANG level sorcery. Everything is a hammer if all you have to deal with are nails.
• dev_l1x_be 1y ago
  And Rust is the best thing to happen to CS in a decade
• semiinfinitely 1y ago
  I had a recent period in my programming career where I started to actually believe that the "worse is better" philosophy is true in practice. It was a dark period and thankfully the existence of tools like uv save me from that abyss.
• cyrialize 1y ago
  I haven't tried uv yet, but I did use it's precursor - rye. I had to update some messy python code and I was looking for a tool that could handle python versions, package updates, etc. with the least amount of documentation needing be read and troubleshooting. Rye was that for me! Next time I write python I'm definitely going to use uv.
  • sirfz 1y ago
    Indeed rye is great and switching to uv is pretty straight forward. I still think rye's use of shims was pretty cool but probably uv's approach is more sane
• magdyks 1y ago
  Huge fan of uv and ruff and starting to play around with ty. Hats of to astral!
• captain_coffee 1y ago
  Yes, uv is probably the best thing to happen to the Py ecosystem in the last decade. That is mainly because the rest of the ecosystem is somewhere between garbage fire and mediocre at best. uv in itself is a great tool, I have no complaints about it whatsoever! But we have to remember just how bad the rest of things are and never forget that everything's still in a pretty bad state even after more than 3 ** DECADES ** of constant evolution.
  • These335 1y ago
    Got a specific example in mind for garbage fire and mediocre?
• nothrowaways 1y ago
  Does speed really matter during python installation?
  • sunshowers 1y ago
    Yes. Technical excellence is a virtue in and of itself.
    • mwcampbell 1y ago
      This! I'm tired of the constant calls to be as mediocre as we can get away with, in the name of getting things done faster and cheaper.
  • collinmanderson 1y ago
    It's fast enough that sometimes dependencies can be checked and resolved and installed at program runtime rather than it needing to be a separate step. You can go from no virtual environment, and just "uv run myfile.py" and it does everything that's needed, nearly instantly.
  • maccard 1y ago
    Speed matters everywhere. How much compute is spent on things that could easily be 100x faster than they are? Compare using VMware with pip to run a battery of unit tests with firecracker plus uv. It’s orders of magnitude quicker, and avoids a whole suite of issues related to persistent state on the machine
  • zahlman 1y ago
    On my system, Pip takes noticeable time just to start up without ultimately doing anything of importance: $ time pip install ERROR: You must give at least one requirement to install (see "pip help install") real 0m0.356s user 0m0.322s sys 0m0.036s (Huh, that's a slight improvement from before; I guess pip 25.3 is a bit better streamlined.)
    • andy99 1y ago
      lol who is using pip so much that .36s of startup time matters to them? This, if presumably uv can do nothing slightly faster, is an absolutely meaningless benefit
• pjmlp 1y ago
  Using Python on and off for OS scripting since version 1.6. It has always been enough to place installations in separate directories, and use the same bash scripts for environment variables configuration for all these years.
• j45 1y ago
  uv has definitely helped make python a first class citizen in more ways.
• isodev 1y ago
  Or is it a corporate grab to gain more influence in the ecosystem? I like the idea, but for profit backing is out of the question. This lesson has been learned countless times.
  • dcgudeman 1y ago
    no, it's a python library, get a grip. Also "This lesson has been learned countless times"? No it hasn't, since when has a package manager developed by a for-profit company hurt the ecosystem?
    • antod 1y ago
      Was that a dig at the recent RubyGems situation?
  • wiseowise 1y ago
    Even if it was, that would be the best implementation of the strategy ever.
  • collinmanderson 1y ago
    They plan on making money by running private package registries, rather than making money on the client. https://astral.sh/pyx https://astral.sh/pyx
    • LtWorf 1y ago
      What they say today and what will the board decide to do in 6 months are 2 entirely separate things.
  • insane_dreamer 1y ago
    its OSS
  • collinmanderson 1y ago
    Does the conda package manager have the same issue?
• an_guy 1y ago
  All these comments look like advertisement. "uv is better than python!!", "8/10 programmers recommend uv", "I was a terrible programmer before but uv changed my life!!", "uv is fast!!!"
  • collinmanderson 1y ago
    > All these comments look like advertisement. "uv is better than python!!", "8/10 programmers recommend uv", "I was a terrible programmer before but uv changed my life!!", "uv is fast!!!" Have you tried uv?
    • an_guy 1y ago
      Why would I? Does it offer something that standard python tools doesn't? Why uv over, lets say, conda?
      • andy99 1y ago
        FWIW I asked the same question last time a uv thread was posted (two weeks ago) - got some legit answers, none that swayed me personally but I can see why people use it. Also lots of inexplicable love for it https://news.ycombinator.com/item?id=45574550 https://news.ycombinator.com/item?id=45574550
        • collinmanderson 1y ago
          I agree that the speed improvements are inexplicable, as in I can't convince you in writing. "uv is fast!!!" doesn't do it justice. You kinda just have to experience it for yourself. If you haven't spent 5 minutes trying it out, you don't know what you're missing. If you're worried about getting addicted like everyone else, I could see that as a valid reason to never try it in the first place.
      • dragonwriter 1y ago
        > Does it offer something that standard python tools doesn't? Other than speed and consolidation, pip, pipx, hatch, virtualenv, and pyenv together roughly do the job (though pyenv itself isn’t a standard python tool.) > Why uv over, lets say, conda? Support for Python standard packaging specifications and consequently also easier integration with other tools that leverage them, whether standard or third party.
• tootie 1y ago
  I've been using uv and am pleased that is about as useful as maven was the last time I used it 12 years ago. I'm not really sure why we still need venv.
• taeric 1y ago
  I still feel bitten by diving into poetry when starting some projects. Has the ecosystem fully moved on to uv, now? Do they have good influence on what python's main ecosystem is moving to?
  • collinmanderson 1y ago
    > Has the ecosystem fully moved on to uv, now? It's moving pretty quick. > Do they have good influence on what python's main ecosystem is moving to? Yes, they're an early adaptor/implementer of the recent pyproject.toml standards.
    • taeric 1y ago
      As someone that is fine on poetry for a few things, is there a good pitch deck on why I should change over?
      • collinmanderson 1y ago
        The best pitch deck is spending 5 minutes playing with uv and trying out installing the dependencies for your project. It’s hard to demonstrate the speed difference in a pitch deck.
        • taeric 1y ago
          Fair. I don't even know how long that takes for my projects. I presume I've been fortunate that that is not one of my long poles, as it were. Hopeful that a lot of this will be even more resolved next time I'm looking to make decisions.
  • 0xpgm 1y ago
    I for now prefer to stick to whatever the default is from the python packaging crew and standard library i.e. `python -m venv` and `pip install` inside of it. Python for me is great when things can remain as simple to wrap your head around as possible.
• hardwaregeek 1y ago
  I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
  • WesolyKubeczek 1y ago
    I somehow had quite enough problems going from bundler 1.13 to 1.16 to 2.x some years ago. I’m glad we have killed that codebase with fire.
  • gigatexal 1y ago
    the thing is I never had issues with virtual environments -- uv just allows me to easily determine what version of python that venv uses.
    • j2kun 1y ago
      you mean you can't just do `venv/bin/python --version`?
      • shlomo_z 1y ago
        he means "choose", not "check"
        • gigatexal 1y ago
          Yes sorry you’re correct. It allows me to specify a version of Python.
  • icedchai 1y ago
    poetry gave us lock files and consistent installs for years. uv is much, much faster however.
    • 1y ago
• devlovstad 1y ago
  uv has made working with different python versions and environments much, much nicer for me. Most of my colleagues in computational genomics use conda, but I've yet to encounter a scenario where I've been unable to just use uv instead.
• bfkwlfkjf 1y ago
  The best thing about uv is it's not conda. Pip is also not conda, but uv is way faster than pip.
• samgranieri 1y ago
  I'm not a pythonista, and the most recent time I've been playing with python has been using octodns. origninally I was using a pip setup, and honestly wow UV was so much faster. I'm very happy the python community has better tooling.
• hirako2000 1y ago
  A problem remain in that many and still more of the popular repositories don't use uv to manage their dependencies. So you are back having to use conda and the rest. Now, you have yet another package manager to handle. I wouldn't be harsh to engineers at astral who developed amazing tooling, but the issue with the python ecosystem isn't lack of tooling, it is the proliferation and fragmentation. To solve dependency management fully would be to incorporate other package descriptors, or convert them. Rsbuild, another rust library, for the node ecosystem did just that. For building and bundling. They came up with rspack, which has large compatibility with the webpack config. You find a webpack repo? Just add rsbuild, rspack, and you are pretty much ready to go, without the slow (node native) webpack.
  • oblio 1y ago
    Don't they publish to PyPi? What do you care what they use behind the scenes?
    • hirako2000 1y ago
      It isn't what they use under the scene. I refered to the interfaces of other packaging tools. I use uv and it's excellent on its own. You get a repo, it's using playwright, what do you do now ? You install all the dependencies found in the dependency descriptor then sync to create a uv descriptor. or you compose a descriptor that uv understands. It's repetitive, rather systematic so it could be automated. I should volunteer for a PR but my point is introducing yet another tool to an ecosystem suffering a proliferation of build and deps management tooling expands the issue. It would have been helpful from the get go to support existing and prolific formats. pnpm understands package.json It didn't reinvent the wheel be cause we have millions of wheels out there. It created its own pnpm lock file, but that's files a user isn't meant to touch so it goes seamlessly to transition from npm to pnpm. Almost the same when migrating from webpack to rsbuild.
      • keyliejener 1y ago
        [dead]
• pama 1y ago
  I love uv. But the post starts with a simple install using a oneliner curl piping to sh, which is such a big attack surface area… I would much rather have a much longer one liner that increases safety.
  • oblio 1y ago
    Isn't uv like... a Rust binary? If that sh has any sense it just copies the binary and adds it to PATH.
    • rieogoigr 1y ago
      but since you are curling a web URL straight to sh you will never know. which is the problem.
      • bmicraft 1y ago
        But it's not if you trust the url and curl has `--proto '=https' --tlsv1.2` as args
      • oblio 1y ago
        What about running a downloaded binary installer? What if the URL is HTTPS?
    • dboon 1y ago
      If you look at the script, this is indeed more or less what happens. Except the folks over there are very clever about ergonomics, so the script is quite long so it can detect your architecture, OS, and even libc to give you an appropriate binary. There’s a tool that they use (which they wrote) which generates such install scripts for you It’s really excellent stuff
  • hirako2000 1y ago
    It seems to be a trend in the rust community. I guess because rustup is suggested to be installed that way. But you don't have to. Brew and other package managers hold uv in their registries.
• mhogers 1y ago
  Seeing a `pip install -r requirements.txt` in a very recently created python project is almost a red flag now...
  • deleted 1y ago
    [deleted]
  • nomel 1y ago
    requirements.txt allows pip arguments to be included, so can be doing much more than just listing package names. For example, installing on an air gapped system, where uv barely has support.
• FattiMei 1y ago
  But what was wrong with pip, venv and pyproject.toml in the first place? I just keep a system installation of python for my personal things and an environment for every project I'm working on. I'd get suspicious if a developer is picky about python versions or library versions like what crazy programs are you writing?
  • wrs 1y ago
    The pytorch ecosystem, for one, is notorious for very specific version dependencies between libraries.
  • jvanderbot 1y ago
    What was wrong was that you needed to do that. How many commands are required to build up a locally consistent workspace? Modern package managers do that for you.
  • oblio 1y ago
    How do pip and venv integrate with pyproject.toml? At least pip doesn't even use it.
    • zahlman 1y ago
      As of half a year ago with pip 25.1, it can install from "dependency groups" listed in pyproject.toml: https://ichard26.github.io/blog/2025/04/whats-new-in-pip-25.1/ https://ichard26.github.io/blog/2025/04/whats-new-in-pip-25.... Pip also generates PEP 751 lockfiles, and installing from those is on the roadmap still (https://github.com/pypa/pip/issues/13334 https://github.com/pypa/pip/issues/13334). venv is lower-level tooling. Literally all it does is create a virtual environment — the same kind that uv creates and manages. There's nothing to "integrate".
  • johnfn 1y ago
    As mostly a Python outsider, in the infrequent times that I do use python package management, uv just works. When I use pip I’d get all sorts of obscure error messages that I’d have to go track down, probably because I got some obscure environment detail wrong. With uv I never run into that nonsense.
• wrs 1y ago
  Every time I see one of these comment threads it seems like uv desperately needs a better home page that doesn’t start with a long list of technical stuff. It’s really simple to use, in fact so simple that it confuses people! The home page should be a simplified version of this page buried way down in the docs: https://docs.astral.sh/uv/guides/projects/ https://docs.astral.sh/uv/guides/projects/
• CalChris 1y ago
  Mojo?
  • zahlman 1y ago
    As far as I can tell, Mojo doesn't have very broad adoption. It also isn't actually Python, it just looks like it.
  • ModernMech 1y ago
    Mojo stopped saying out loud they are trying to be a Python superset. Maybe they can do it one day but they're keeping that on the DL now because it's a really big ask.
• kristopolous 1y ago
  Hype is dangerous
• docsaintly 1y ago
  Python venv's is the #1 reason I've avoided working with it more. It used to be #2 behind strong typing, but now that Linux OSes' take up the default python install and block it from being used for quick scripts, it jumped to #1. I've always wondered why Linux OSes that rely on python scripts don't make their own default venv and instead clobber the user's default python environment...
• mosselman 1y ago
  uv is great. I am a Ruby developer and I always loathed having to work with Python libraries because of how bad the tooling was. It was too complex to learn for the one-off times that I needed it and nothing worked properly. Now with uv everything just works and I can play around easily with all the great Python projects that exist.
• j2kun 1y ago
  This article appears to be NOT about someone who discovered uv after using venv/pip, but rather an article about someone who discovered uv after not using virtual environments at all, and is mostly excited about the cleanliness of virtual environments.
  • collinmanderson 1y ago
    The article shows some advantages compared to plain virtual environments: In principle, you can ‘activate’ this new virtual environment like any typical virtual environment that you may have seen in other tools, but the most ‘uv-onic’ way to use uv is simply to prepend any command with uv run. This command automatically picks up the correct virtual environment for you and runs your command with it. For instance, to run a script — instead of source .venv/bin/activate python myscript.py you can just do uv run myscript.py
    • deleted 1y ago
      [deleted]
    • zahlman 1y ago
      > The article shows some advantages compared to plain virtual environments No; they are plain virtual environments. There is no special kind of virtual environment. Uv simply offers its own command structure for managing those environments. In particular, `uv run` just ensures a venv in a specific location, then uses it. There is no requirement to activate virtual environments in order to use them (unless you have some other tooling that specifically depends on the environment variables being set). You can, similarly, "just do" .venv/bin/python myscript.py without uv installed. > This command automatically picks up the correct virtual environment for you Some people dislike such magic, especially since it involves uv having an opinion about where the virtual environment is located.
      • collinmanderson 1y ago
        Sorry, you're right I should have said "plain venv", as in the program. `uv run` will also sync the environment to be sure it exists and meets the correct specifications. But yes, it's optional. You can also just do `uv sync` to sync the environment and then activate it like normal. Or use `uv venv`, `uv pip` commands and just take the speed advantage.
• mannicken 1y ago
  God yes. I got dragged into the uv when I started using copyparty and I am a fanatical admirer ever since. I also use pipx to install tools often. I really don't understand why you can't just pip install something globally. I want this package to be available to me EVERYWHERE, why can't I do it? I only use python recreationally because everyone uses python everywhere and you can't escape it. So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it.
  • collinmanderson 1y ago
    > I really don't understand why you can't just pip install something globally. I want this package to be available to me EVERYWHERE, why can't I do it? I only use python recreationally because everyone uses python everywhere and you can't escape it. So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it. You may have a library that's been globally installed, and you have multiple projects that rely on it. One day you may need to upgrade the library for use in one project, but there are backward incompatibile changes in the upgrade, so now all of your other projects break when you upgrade the global library. In general, when projects are used by multiple people across multiple computers, it's best to have the specific dependencies and versions specified in the project itself so that everyone using that project is using the exact same version of each dependency. For recreational projects it's not as big of a deal. It's just harder to do a recreation of your environment.
  • zahlman 1y ago
    > I want this package to be available to me EVERYWHERE, why can't I do it? Because it being available in the system environment could cause problems for system tools, which are expecting to find something else with the same name. And because those tools could include your system's package manager (like Apt). > So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it. I assume you're referring to the new protections created by the EXTERNALLY-MANAGED marker file, which will throw up a large boilerplate warning if you try to use pip to install packages in the system environment (even with --user, where they can still cause problems when you run the system tools without sudo). You should read one or more of: * the PEP where this protection was introduced (https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/); * the Python forum discussion explaining the need for the PEP (https://discuss.python.org/t/_/10302 https://discuss.python.org/t/_/10302); * my blog post (https://zahlman.github.io/posts/2024/12/24/python-packaging-1/ https://zahlman.github.io/posts/2024/12/24/python-packaging-...) where I describe in a bit more detail (along with explaining a few other common grumblings about how Python packaging works); * my Q&A on Codidact (https://software.codidact.com/posts/291839/ https://software.codidact.com/posts/291839/) where I explain more comprehensively; * the original motivating Stack Overflow Q&A (https://stackoverflow.com/questions/75608323/ https://stackoverflow.com/questions/75608323/); * the Python forum discussion (https://discuss.python.org/t/_/56900 https://discuss.python.org/t/_/56900) where it was originally noticed that the Stack Overflow Q&A was advising people to circumvent the protection without understanding it, and a coordinated attempt was made to remedy that problem. Or you can watch Brodie Robertson's video about the implementation of the PEP in Arch: https://www.youtube.com/watch?v=35PQrzG0rG4 https://www.youtube.com/watch?v=35PQrzG0rG4.
• aurintex 1y ago
  I can only agree. I'm not an python expert, but I always struggled when installing a new package and got the warning, that it could break the system packages, or when cloning an existing repo on a new installed system. Always wondered, why it became so "complicated" over the years.
  • zahlman 1y ago
    > Always wondered, why it became so "complicated" over the years. Please see https://news.ycombinator.com/item?id=45753142 https://news.ycombinator.com/item?id=45753142.
• peter-m80 1y ago
  So basically a node-like thing for python
• talsperre 1y ago
  uv is the best tool out there as long as you have python only dependencies. It's really fast, and you can avoid using poetry, pipenv, etc. The only reason for conda to still exist is non pythonic dependencies, but that's another beast to tackle in itself.
• samuel2 1y ago
  Reminds me of Julia's Pkg manager and the way Julia packages are managed (also with a .toml file). That's the way to go!
• eisbaw 1y ago
  nix-shell is the OG
• zmmmmm 1y ago
  > Instead of > > source .venv/bin/activate > python myscript.py > > you can just do > > > uv run myscript > This is by far the biggest turn off for me. The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer. Side rant: yes I get triggered whenever someone tells me "you can just" do this thing that is actually longer and worse than the original.
  • dragonwriter 1y ago
    > They need to run natively how they are supposed to when the environment is set, not put through a translation layer. There is a new standard mechanism for specifying the same things you would specify when setting up a venv with a python version and dependencies in the header of a single file script, so that tooling can setup up the environment and run the script using only the script file itself as a spec. uv (and PyPA’s own pipx) support this standard. > yes I get triggered whenever someone tells me "you can just" do this thing that is actually longer and worse than the original. "uv run myscript" is neither longer nor worse than separately manually building a venv, activating it, installing dependencies into it, and then running the script.
  • mborsuk 1y ago
    From what I can tell (just started using uv) it doesn't break the original workflow with the venv, just adds the uv run option as well.
    • wtallis 1y ago
      Yes, you still have the option of manually activating a venv, and that makes sense if the amortized cost of that is lower than several instances of typing `uv run `. Though sometimes when working in one project with its venv activated, I end up needing to run a tool from another project with a separate vent, so uv still ends up being useful.
  • collinmanderson 1y ago
    > The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer. The `uv run` command is an optional shortcut for avoiding needing to activate the virtual environment. I personally don't like the whole "needing to activate an environment" before I can run commands "natively", so I like `uv run`. (Actually for the last 10 years I've had my `./manage.py` auto-set up the virtual environment for me.) The `uv add` / `uv lock` / `uv sync` commands are still useful without `uv run`.
• hkt 1y ago
  Am I the only one who thought poetry was still the greatest available whizbang?
  • raduan 1y ago
    been great maybe 5 years ago. Just migrated all of my projects from poetry to uv and it's been a big productivity boost for everyone: myself, agents, my CI and CD
• ModernMech 1y ago
  Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.
  • wiseowise 1y ago
    Who cares what it is written in?
    • ModernMech 1y ago
      It's called dogfooding -- writing tools for the language in the language. Not doing so here, where the result is "best thing to happen to the ecosystem in a decade", is a tacit admission that Python isn't up for the task of writing best-in-class Python tooling (the use of Rust wasn't incidental). Having seen uv, people will probably start writing more Python-ecosystem projects in Rust. Which is fine, Python is not for everything.
    • sunshowers 1y ago
      Rust's rigorous separation of immutable and mutable state consistently leads to higher-quality software that stands the test of time.
      • t43562 1y ago
        C has stood a very great test of time and we don't ascribe virtue to it.
  • zahlman 1y ago
    No, the "best thing that happened" (in TFA's author's opinion) is that this specific tool exists, with its particular design. Rust is an implementation detail. Most of the benefit that Uv offers over pip, in my analysis, is not a result of being written in Rust. 3.14 is a big deal.
    • 1y ago
• quantum_state 1y ago
  Running pytest with uv run —active pytest… is very slow to get it started … anyone has some tips on this?
• tonymet 1y ago
  Can someone steelman the python tooling ecosystem for me? Having a new packaging / dependency manager every few years seems excessive.
  • collinmanderson 1y ago
    uv is finally an all-in-one tool that finally takes all of the good ideas from previous projects and combines them together to work well as one (and unbelievably fast). The fact that it's a binary, not written in python, also simplifies bootstrapping. So you don't need python+dependencies installed in order to install your python+dependencies.
    • tonymet 1y ago
      I'm hoping for the best. now there's a lot of CI and Readme.md that will need rewriting
    • antod 1y ago
      One helpful element that has changed over the years compared to the old wild west days is the large number of PEPs that have quietly in the background bit by bit standardized packaging formats and requirements. Some foundations have moved into the stdlib. This means that newer tools are much more compatible with each other and mainly just differ in implementation rather than doing different things altogether. The new stuff is working on a much more standard base and can leave behind many dark crufty corners. Unravelling the legacy stuff and putting the standards in place seems to have taken 15+ years?
  • zahlman 1y ago
    All of these tools are third-party and the Python core development team can't do anything to prevent people from inventing new ones. Even pip is technically at arms length; it has special support in the standard library (Python releases will vendor a wheel for it, which is designed to be able to bootstrap itself for installation[0]), but is developed separately. Standards are developed to allow existing tools to inter-operate; this entails allowing new tools to appear (and inter-operate), too. This system was in some regards deliberate, specifically to support competition in "build backends". The background here is that many popular Python projects must interface to non-Python code provided with the project; in many cases this is code in compiled languages (typically C, Fortran or Rust) and it's not always possible to pre-build for the user's system. This can get really, really complicated, and people need to connect to heavyweight build systems in some cases. The Python ecosystem standards are designed with the idea that installers can automatically obtain and use those systems when necessary. And by doing all of this, Python core developers get to focus on Python itself. Another important concern is that some bad choices were made initially with Setuptools, and we have been seeing a very long transition because of a very careful attitude towards backwards compatibility (even if it doesn't seem that way!) which in turn is motivated by the battle scars of the 2->3 transition. In particular, it used to be normal and expected that your project would use arbitrary Python code (in `setup.py` at the project root) simply to specify metadata. Further, `setup.py` generally expects to `import setuptools`, and might require a specific version of Setuptools; but it can't express its build-time Setuptools version requirement until the file is already running - a chicken-and-egg scenario. Modern projects use a declarative TOML file for "abstract" metadata instead (which is the source for concrete metadata included in the actual build artifacts), but the whole ecosystem still has to support a lot of really outdated ways of doing things, because in part of how much abandonware is out there. [0]: Wheels are zip-compressed, and Python can run code from a zip file, with some restrictions. The pip project is designed to make sure that this will work. The standard library provides a module "ensurepip" which locates this wheel and runs a bootstrap script from that wheel, which will then install into the current environment. Further, the standard library "venv", used to create virtual environments, defaults to using this bootstrap in the newly created environment.
• rieogoigr 1y ago
  Is there a way to install this that doesn't involve piping a random URL to my shell interpreter?
  • wiseowise 1y ago
    Pip.
  • deleted 1y ago
    [deleted]
  • zahlman 1y ago
    Uv is available as a wheel from PyPI, so you can in fact `pip install uv` into an appropriate environment. Since it provides a command-line binary, Pipx will also happily install it into an environment it manages for you. And so on and so forth. (You can even install uv with uv, if you want to, for whatever reason.) The wheel basically contains a compiled ~53MB (huh, it's grown in recent versions) Rust executable and a few boilerplate files and folders to make that play nice with the Python packaging ecosystem. (It actually does create an importable `uv` module, but this basically just defines a function that tells you the path to the executable.) If you want it in your system environment, you may be out of luck, but check your full set of options at https://docs.astral.sh/uv/getting-started/installation/ https://docs.astral.sh/uv/getting-started/installation/ . The install script does a ton of system introspection. It seems to be structured quite similarly to the Julia installer, actually.
    • zahlman 1y ago
      > If you want it in your system environment, you may be out of luck That was silly of me; since all you need is the compiled executable, you can just move it to an appropriate place (that doesn't interfere with the system package manager; so, /usr/local/bin, or /opt/bin) after user installation.
• pshirshov 1y ago
  And still there are some annoying issues: dependencies = [ "torch==2.8.0+rocm6.4", "torchvision==0.23.0+rocm6.4", "pytorch-triton-rocm==3.4.0", ... ] There is literally no easy way to also have a configuration for CUDA, you have to have a second config, and, the worse, manually copy/symlink them into the hardcoded pyproject.toml file
  • sirfz 1y ago
    Checkout dependency groups and uv conflicts configuration
• jillesvangurp 1y ago
  Python is not my first language but I've always liked it. But project and dependency management was always a bit meh and an afterthought. Over the years, I've tried venv, conda, pipenv, petry, plain pip with requirements.txt. I've played with uv on some recent projects and it's a definite step up. I like it. Uv actually fixes most of the issues with what came before and actually builds on existing things. Which is not a small compliment because the state of the art before uv was pretty bad. Venv, pip, etc. are fine. They are just not enough by themselves. Uv embraces both. Without that, all we had was just a lot of puzzle pieces that barely worked together and didn't really fit together that well. I tried making conda + pipenv work at some point. Pipenv shell just makes using your shell state-full just adds a lot of complexity. None of the IDEs I tried figured that out properly. I had high hopes for poetry but it ended up a bit underwhelming and still left a lot of stuff to solve. Uv succeeds in providing a bit more of an end to end solution. Everything from having project specific python installation, venv by default without hassle, dependency management, etc. My basic needs are simple. I don't want to pollute my system python with random crap I need for some project. So, like uv, I need to have whatever solution deal with installing the right python version. Besides, the system python is usually out of date and behind the current stable version of python which is what I would use for new projects.
• aranw 1y ago
  For years I've avoided using Python tools because I've always struggled to get them working properly. Will uv solve this pain for me? Can I install a Python app globally with it?
• nova22033 1y ago
  First time I tried to teach my son java, I realized how badly it's missing a built in dependency management system.
• warbaker 1y ago
  Does uv handle CUDA versioning? This is the big reason I'm still on conda -- I can save a whole environment with `conda list --explicit`, including CUDA stuff, and I can set up a new machine with the same environment just from that file.
  • collinmanderson 1y ago
    It handles CUDA version for PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/#installing-pytorch https://docs.astral.sh/uv/guides/integration/pytorch/#instal...
    • warbaker 1y ago
      Thanks for this - does this actually install CUDA, or just give a pytorch install for a particular CUDA version?
• marsven_422 1y ago
  [dead]
• alienbaby 1y ago
  Can I just start using python if I've already got a bunch of projects manage with venv / pyenv / virtualenv ( and tbh I've kinda got into a confused mess with all these venv things, and at this point just hope they all keep working...)
• Areibman 1y ago
  My biggest frustration is the lack of a good universal REPL to just play around with. It's frustrating how I have to run `uvx --with x,y,z ipython` every single time I just want to spin up some python code which may or may not use packages. (Hard to overstate how annoying it is to type out the modules list). To me, Python's best feature is the ability to quickly experiment without a second thought. Conda is nice since it keeps everything installed globally so I can just run `python` or iPython/Jupyter anywhere and know I won't have to reinstall everything every single time.
  • embeng4096 1y ago
    Would creating a `main.py` with the dependencies installed either as a uv project or inline work for you? One thing I did recently was create a one-off script with functions to exercise a piece of equipment connected to the PC via USB, and pass that to my coworkers. I created a `main.py` and uv add'ed the library. Then when I wanted to use the script in the REPL, I just did `uv run python -i main.py`. This let me just call functions I defined in there, like `set_led_on_equipment(led='green', on=True)` directly in the REPL, rather than having to modify the script body and re-run it every time. Edit: another idea that I just had is to use just[0] and modify your justfile accordingly, e.g. `just pything` and in your justfile, `pything` target is actually `uv run --with x,y,z ipython` Edit edit: I guess the above doesn't even require just, it could be a command alias or something, I probably am overengineering that lol. [0]: https://github.com/casey/just https://github.com/casey/just
• forrestthewoods 1y ago
  uv is spectacular But I’m utterly shocked that UV doesn’t support “system dependencies”. It’s not a whole conda replacement. Which is a shame because I bloody hate Conda. Dependencies like Cuda and random C++ libraries really really ought to be handled by UV. I want a true genuine one stop shop for running Python programs. UV is like 80% of the way there. But the last 20% is still painful. Ideally UV would obsolete the need for docker. Docker shouldn’t be a requirement to reliable run a program.
  • dirkc 1y ago
    Does uv use a sandbox or do process isolation? I've switched to running any and all python projects in Docker as a way to ensure that low effort supply chain attacks doesn't easily get everything in my home dir. So even if I use uv, I'd only do that in a Docker image for now
    • forrestthewoods 1y ago
      No idea. Probably not? Docker images are a productivity killer. I don’t want to waste even 1 second building an image. And all the hoops you have to jump through to enable rapid iteration aren’t worth it. Docker Images are fine - I guess - for deployment. But for development I absolutely hate them.
  • zoobab 1y ago
    Ideally uv pip install mypackage should work 100% of the time, but that's far from the case.
  • zahlman 1y ago
    > Dependencies like Cuda and random C++ libraries really really ought to be handled by UV. Currently, there isn't a way for the packages to specify these dependencies. In part because of the complexity of explaining exactly what is needed (and where to look for it, if you're expecting the system to provide it outside of what Python manages itself). See https://peps.python.org/pep-0725/ https://peps.python.org/pep-0725/ and https://pypackaging-native.github.io/ https://pypackaging-native.github.io/ for details.
• eikenberry 1y ago
  I either want one universal tool that can manage this sort of thing across multiple languages (eg. devenv) or a native, built-in tool (eg. go's tooling). I don't see how this is any different from all the previous incarnations of Python's project/package management tools. The constant churning of 3rd party tooling for Python was one of the main reasons I mostly stopped using it for anything but smaller scripts.
  • 9dev 1y ago
    The difference is that this one is actually good. So good, in fact, that there is considerable momentum and thus adoption with this tool, and I wouldn’t be surprised if it reaches a similar state like npm is for node eventually.
• __mharrison__ 1y ago
  The best things since f-strings... I'm teaching (strongly recommending/forcing using) uv in all my courses now.
• canto 1y ago
  ffs, stop installing stuff by piping random scripts from the internet to shell!!1one
• didip 1y ago
  UV indeed is a blessing. Love it. Hopefully it gets recommended as the official one.
  • LtWorf 1y ago
    It's VC backed. I have 100% confidence that it will end up badly.
• jonnycomputer 1y ago
  How is this different than (or better than) pyenv?
• logicprog 1y ago
  Uv existing is what made me willing to use Python as my primary prototype/experiment language!
• grigio 1y ago
  yes
• fortran77 1y ago
  Why is it written in Rust though? I'd prefer a pure Python solution.
• richstokes 1y ago
  I recently discovered you can use uv to run code direct from a git repo. No need to clone/manually install packages first. E.g. `uvx --from "git+https://github.com/richstokes/meshtastic_terminal.git https://github.com/richstokes/meshtastic_terminal.git" meshtastic-tui`
• senderista 1y ago
  It’s puzzling why Python became the de facto standard scripting language rather than Ruby when the tooling was so inferior.
  • cidd 1y ago
    AI/ML
    • collinmanderson 1y ago
      > AI/ML The Machine-Learning world, especially "Google Brain" research team figured out that NumPy was an awesome piece of software for dealing with large arrays of numbers and matrix multiplication. They built "TensorFlow" on top of it around 2015 which became very popular. Facebook followed suit and released PyTorch in 2016. IPython/Jupiter notebooks (for Julia, Python and R) from 2015 were another factor, also adopted by the AI/ML community. The alternative data-science languages at the time were Mathematica, MATLAB, SAS, Fortran, Julia, R, etc, but Python probably won because it was general purpose and open source. I suspect Python would not have survived the 2/3 split very well if it wasn't for AI/ML adopting Python as its main language. > when the tooling was so inferior Since 2012, Conda/Anaconda has been the go-to installer in the SciPy/NumPy world which also solves a lot of problems that uv solves.
  • nhumrich 1y ago
    Perhaps the language design is more important than the tooling?
    • senderista 1y ago
      How do you think Python's language design is superior to Ruby's?
      • nhumrich 1y ago
        Readability > write ability Rubies meta-prigramming often leads to too much magic, lack of understanding.
• zelphirkalt 1y ago
  Hmpf. I am using uv now, but I have been doing fine before using poetry. For me it is not a huge revolution, as I always value reproducibility, which means lock file and checksums, and that, I was able to have before using poetry. Yes, yes, ... uv is faster. I grant them that. And yes, it's pleasant, when it runs so quickly. But I am not changing dependencies that often, that this really impacts my productivity. A venv is created, it stays. Until at some point I update pyproject.toml and the lock file. Since I am mostly avoiding non-reproducible use-cases, like for example stating dependencies inside the python scripts themselves, without checksums, only with versions, and stuff like that, I am not really benefiting that much. I guess, I am just not writing enough throwaway code, to benefit from those use-cases. Some people here act, like uv is the first tool ever to install dependencies like npm and cargo and so on. Well, I guess they didn't use poetry before, which did just that.
  • skavi 1y ago
    poetry was incredibly slow and flaky in my experience.
    • zelphirkalt 1y ago
      I've used it in various work projects/services, and in my free time in various projects. Never had anything "flaky" about it happening. Care to elaborate what you mean by that?
• sheepscreek 1y ago
  What about Pixi[1]? It has become an irreplaceable part of my dev stack. Fantastic for tool + library version management. It has replaced a number of tools for me and greatly simplified bootstrapping in a new environment (like lxc containers when I am experimenting with stuff) or creating a lightweight sandbox for AI agents. 1. https://pixi.sh/latest/ https://pixi.sh/latest/
• tehnub 1y ago
  Before uv, I was fairly happy with pyenv + venv + pip for development and pipx for running "tools". IMO, the specific things uv improves upon are: - Faster dependency resolution. In fact, everything uv does is extremely fast. - Better ergonomics in a dozen ways (`uv run` instead of activating the virtual env, support for script metadata to run scripts with dependencies, uv add to modify the pyproject.toml (that it created for you), etc.) - Stack of one tool instead of four+ - Easier Python installation (although I usually use both pyenv and uv on my machine)
  • tclancy 1y ago
    The speed thing can’t be overstated. At first I thought it wasn’t actually running for some things.
• petralithic 1y ago
  Rust is the best thing to happen to the Python (and JS) ecosystem in a decade. Once people realized that the tooling doesn't need to be written in the same language as the target language, it opens up all sorts of performance possibilities.
• ggm 1y ago
  This blog very strongly echoes my own experiental sense of the field of play. It's just simpler to use, and better overall. It's reduced friction significantly. I think the Python community should put it as a first preference vehicle, and be respectful to the prior arts, and their developers, but not insist they have primacy.
• SafeDusk 1y ago
  UV script enabled me to distribute a MCP client or server in a single file[0]. [0]: https://blog.toolkami.com/mcp-server-in-a-file/ https://blog.toolkami.com/mcp-server-in-a-file/
• ederamen 1y ago
  Uv is so good. I'm a curmudgeon about adopting new tooling, and tried uv with a lot of skepticism, but it was just better in every way. And even if it wasn't so polished and reliable, the raw speed makes it hard to go back to any other tool. Uv combined with type hints reaching critical mass in the Python ecosystem, and how solid PyLance is in VSCode, feels so good it has made me consider investing in Python as my primary language for everything. But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. I know the performance meta in Python is to...not use python (bind to C, Rust, JVM) - and you can get pretty far with that (see: uv), but I'd rather spend my limited time building expertise in a language that isn't constantly hemorrhaging resources unless your code secretly calls something written in another language :/ There are so many good language options available today that compete. Python has become dominant in certain domains though, so you might not have a choice - which makes me grateful for these big steps forward in improving the tooling and ecosystem.
  • Jaxkr 1y ago
    On performance: 3.13 removed the GIL and added experimental first-party JIT (like PyPy). In two years I bet we’ll be seeing v8 level performance out of CPython.
    • motoboi 1y ago
      I bet we’ll be seeing python compiled to JVM of getting JVM levels of performance. Much better than v8
      • necovek 1y ago
        There have for a long time been IronPython (CLR) and and Jython (JVM). But, they don't have the full compatibility with CPython, so nobody really picks them up.
        • CamouflagedKiwi 1y ago
          Jython seems to be effectively dead though - it only has 2.7 compatibility.
• zelphirkalt 1y ago
  From the article: > uv is an incredibly powerful simplification for us that we use across our entire tech stack. As developers, we can all work with identical Python installations, which is especially important given a number of semi-experimental dependencies that we use that have breaking changes with every version. On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers. > It’s just so nice to always know that Python and package installation will always be handled consistently and correctly across all of our machines. That’s why uv is the best thing to happen to the Python ecosystem in a decade. I can only conclude, that the author of the article, and perhaps even the organization they work in, is unaware of other tools that did the job long before uv. If they really value reproducibility that much, how come they didn't look into the matter before? Things much have been really hastily stitched together, if no one ever looked at existing tooling before, and only now they make things reproducible. I guess reproducibility is still very much a huge problem, especially in jobs, where it should be one of the most important things to take care of: Research. ("Astronomer & Science Communicator" it says on the website). My recommendation is: Get an actual software developer (at least mid-level) to support your research team. A capable and responsibly acting developer would have sorted this problem out right from the beginning. I am glad they improved their project setups to the level they should be at, if they want to call it research.
  • collinmanderson 1y ago
    > I can only conclude, that the author of the article, and perhaps even the organization they work in, is unaware of other tools that did the job long before uv. If they really value reproducibility that much, how come they didn't look into the matter before? Things much have been really hastily stitched together, if no one ever looked at existing tooling before, and only now they make things reproducible. Yes, Poetry has had lock files for years, and pyenv has been able to manage installations, but uv is "an incredibly powerful simplification" that makes it easy to do everything really well with just one tool.
    • acdha 1y ago
      Also, I kinda feel dirty criticizing an open source project but Poetry seems to be struggling with technical debt. I hit bugs which have been open for years or stuff which is WONTFIXed, and while they truly do not owe me anything, it’s a lot more rewarding to use uv where I hit fewer issues in general and the stuff I do hit is usually fixed quickly. There’s a bigger conversation about open source maintenance there, but if I have to get my job done it’s increasingly tempting to take the simplifications and speed.
• rayxi271828 1y ago
  I love how uv allows me to not think of all the options anymore. virtualenv, venv, pyenv, pipenv... I think at one point the recommended option changed because it was integrated into Python, but I can't even remember which is which anymore. Such a pleasure to finally have just one, for maybe... ~99% of my needs.
• rkagerer 1y ago
  This looks awesome. But why is it the Windows installation is to execute a script off the Internet with bypassed security isolations? powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 https://astral.sh/uv/install.ps1 | iex"
• metmac 1y ago
  UV and the crew at Astral really moved the Python packaging community forward. I would love to see them compete with the likes of Conda and try to handle the Python C extension story. But in the interim, I agree with everyone else who has already commented, Pixi which is partly built atop of UV’s solver is an even bigger deal and I think the longer term winner here. Having a topologically complete package manager who can speak Conda and PyPi, is amazing. https://pixi.sh/latest/ https://pixi.sh/latest/
• throwaway7783 1y ago
  Been using pip and venv for long. I get uv is faster, but I don't get why people drool over it this much. What is wrong with pip + venv? I build webapps so perhaps I don't see issues in ML world
• bonyt 1y ago
  uv is fast enough that you can put things like this in your profile: alias ytd="uv tool upgrade yt-dlp && yt-dlp" Which is pretty cool.
  • superfish 1y ago
    Why not just ytd=“uvx yt-dlp”?
• barrrrald 1y ago
  I’m surprised not to see a discussion of the biggest drawback: despite being fewer characters, “uv” is harder to type than “pip”. It requires two different hands to participate and a longer reach with my left index finger. pip is convenient – just a little rattle off with my right hand.
  • toenail 1y ago
    Linters and formatters are things you shouldn't have to run by hand.. that's what you have CIs, git hooks, IDEs, etc for
  • zahlman 1y ago
    > “uv” is harder to type than “pip”. It requires two different hands to participate and a longer reach with my left index finger. I'm not convinced. "pip" uses one's weaker ring finger; "v" is adjacent to "f"; and alternating hands should be easier for a touch typist.
• haiji2025 1y ago
  May I ask whether I can obtain the product I want by describing it directly?
• helicone 1y ago
  sunlight really IS the best disinfectant
• panzi 1y ago
  > uv is straightforward to install. How do I install it globally on a system? Debian doesn't let me install packages via pip outside of a venv or similar.
  • zahlman 1y ago
    Get a local install, then copy, move or symlink it into e.g. /usr/local/bin with sudo. It's an all-in-one statically compiled executable. (The pip-installable wheel contains this executable plus some irrelevant window dressing.)
• orliesaurus 1y ago
  the hilarious part is that uv is written in rust
• bicepjai 1y ago
  I completely agree. Deploying Python packages like MCP servers has been a real game changer. I'm so glad the days of wrestling with conda environments and Jupyter kernels are behind us. I used to start personal projects, decide to clean up my Python setup first, and inevitably give up on the project after getting lost in the cleanup.
• random3 1y ago
  It's surprising to me how long it can take for some languages to get decent package management solutions. There are no silver bullets because it's tricky to "encode" compatibility in a version number. I personally think semver helped a little and damaged a lot more by selling a pseudo solution that stands no chance to solve the real problem it needs to. Maven has always been a very good solution. I think Bazel is too, but haven't had much experience with it.
• deleted 1y ago
  [deleted]
• biglost 1y ago
  I'm weird, this opinion Is even weirder, but how about start removing what makes Python slow? Sometimes you need yo remove features. It's hard, a pain but i dont see any other way of fixing really big mistakes...
• orangeisthe 1y ago
  why is a uv README the top post on HN??
  • deleted 1y ago
    [deleted]
• armeet 1y ago
  uv brings some organization to the hell that is python package management
• AbuAssar 1y ago
  why uv is not included by default with the standard Python binary installers?
  • thomspoon 1y ago
    Because uv is still beta software and doesn’t conform to 100% of the PEPs currently available due to that being a lot of work
  • zahlman 1y ago
    Because officially blessing one packaging tool (or set of packaging tools) is considered out of scope for the core Python project. Even pip is provided in a very indirect way.
• namanyayg 1y ago
  Is there a resource to understand the nuanced technical differences between pip and uv? As an outsider to the python ecosystem I've wanted to learn the _how_ behind uv as well, but that hasn't been immediately clear
  • zahlman 1y ago
    I'm hoping to get back to my blogging (and other general productivity...) soon, and I will definitely have some of those things among my upcoming topics.
• himyathanir 1y ago
  The popularity of uv marks the commercialization of the python ecosystem. And in this case by a company whose business model is totally elusive to me. Not a fan.
• pulkitsh1234 1y ago
  uv has been my sole reason to come back to Python for coding. It was just too time consuming to setup a working dev environment with Python locally.
  • never_inline 1y ago
    This is just not true. Poetry existed for a while. It was slower than uv but not a deal breaker.
• ValtteriL 1y ago
  My go-to development environment for Python projects is nowadays Nix for uv, and uv for Python deps. Nix does not play well with python dependencies. It's so nice to have that part taken care in a reproducible manner by uv.
• BrenBarn 1y ago
  The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see uv doesn't make this easy.
  • taftster 1y ago
    You can't just create yourself an "everything" environment with UV and then experiment with it? Honest question. I think you're basically suggesting that you'd have a VM or something that has system-high packages already preinstalled and then use UV on top of it?
    • BrenBarn 1y ago
      If so, it's certainly not obvious. I mean look at the docs: https://docs.astral.sh/uv/getting-started/features/ https://docs.astral.sh/uv/getting-started/features/ I don't see anything resembling "environments" in the list of features or in the table of contents. In some sections there is stuff like "When working on a project with uv, uv will create a virtual environment as needed", but it's all about environments as tied to particular projects (and maybe tools). You can use the `uv venv` and the `uv pip` stuff to create an environment and install stuff into it, but this isn't really different from normal venvs. And in particular it doesn't give me much benefit over conda/mamba. I get that the project-based workflow is what a lot of people want, and I might even want it sometimes, but I don't want to be forced into foregrounding the project.
      • jcattle 1y ago
        > And in particular it doesn't give me much benefit over conda/mamba. How about the advantage of not taking an entire lunch break to resolve the environment every time you go to install a new library? That was the biggest sticking point with conda/mamba for me. It's been a few years since I last used them but in particular with geospatial packages I would often run into issues.
• culebron21 1y ago
  Looks similar to buildout 15 years ago. It also made you a local executable `./bin/python`, with its own PYTHON_PATH. Then everyone rushed to virtualenv.
• sanskarix 1y ago
  [dead]
  • darkamaul 1y ago
    I think better developer tools tend to compound over time, they raise expectations and push the whole ecosystem forward. IMO, uv is quickly becoming one of the best reasons to start a new project in Python. It’s fast, and brings a level of polish and performance that makes Python feel modern again.
    • lawn 1y ago
      Indeed. It's interesting to compare the expectations of a new programming language today to just a decade ago for instance.
      • oblio 1y ago
        The funky thing is that people will fork uv and make package managers for other programming languages from it. Or at least from parts of it. Win win.
    • ModernMech 1y ago
      I think uv is one of the best examples of why not to start a new project in Python. I mean, depending on the project really, Python has its place. But if your project is anything like uv, uv proves you can't actually write an app like uv in Python. So for as great as uv is, its proximity to Python is a constant reminder of its shortcomings.
      • arcanemachiner 1y ago
        A car doesn't move as fast as an airplane can. Therefore, cars are useless and nobody should use one.
        • ModernMech 1y ago
          I had said: "I mean, depending on the project really, Python has its place." My point is if you put an airplane next to a car factory, it's very clear you can't build the airplane in the car factory.
• cluckindan 1y ago
  Finally, npm comes to python-land. :-)
• waldrews 1y ago
  (off topic) The code chunks in the article use a ligature font, so ">=" is rendered in a way that makes you stop to think how to type it - which is especially confusing since the context is not exactly math. Down with ligatures and extra cognitive load!
  • wodenokoto 1y ago
    Some people love this, and hunt for the perfect ligature overloaded programming font. Fira Codes popularity is often credited to its tons of ligatures. I hate it too.
• nicman23 1y ago
  the farce that is python packaging is the reason that 99% of docker images exist
• GamerYou54 1y ago
  Hey have you heard about block0hunt by any chance? Looks like a cicada thing again
• GamerYou54 1y ago
  [flagged]
• pouetpouetpoue 1y ago
  the best thing would be to use the package manager of the os.
• pouetpouetpoue 1y ago
  best thing would be to use the package manager of the os.
• raduan 1y ago
  I just hope that at this point the overtake over Python as a language and can shape it properly for the next 10 years(for AI and also for humans)
• vietvu 1y ago
  Yes, agree. At first I still use pyenv, or mise to manage python version, now that uv does that, uv is the only tool I need for everything in Python env.
• danielhanchen 1y ago
  Super agree! Love how uv installs packages in parallel! It made installs 30 seconds from 5 minutes during `uv pip install unsloth`!
• karel-3d 1y ago
  Another year, another new way of installing python packages?
• moonAA 1y ago
  UV is so cool! These days, I never develop new projects without it.
• lxgr 1y ago
  Couldn't agree more. Arguably this article is missing one of the biggest benefits: Being able to make Python scripts truly self-contained by including dependencies via a PEP 723 inline header and then running them via `uv run <script.py>` [1]. It's made Python my language of choice for one-off scripts easily shareable as gists, scp-able across systems etc. [1] https://pybit.es/articles/create-project-less-python-utilities-with-uv-and-inline-script-metadata/ https://pybit.es/articles/create-project-less-python-utiliti...
  • ndr 1y ago
    If like me you never remember what the header looks like, uv will help there too: `uv init --script myscript.py`
• palata 1y ago
  > curl -LsSf https://astral.sh/uv/install.sh https://astral.sh/uv/install.sh | sh "Just pipe a random script from the internet into your shell! What could possibly go wrong?"
  • joefarish 1y ago
    We've all done it. I'm curious though, I wonder what would be the best way to prevent a user from doing this.
    • palata 1y ago
      The user is the one copy-pasting that line in their terminal. There is no preventing them from doing it, they can `rm -rf /` if they feel like it. They shouldn't, though...
    • redleader55 1y ago
      Wrap curl to detect if /dev/stdout is a pipe and if the output is a script - this is fast because of the hash-bang. From there you can do a lot of fancy things: replace the output with echo "don't do this" ; exit 1", check the Url against a list of well known accepted scripts based on hash, run the unknown ones through an LLM to validate if they are potentially malicious, etc.
      • palata 1y ago
        > run the unknown ones through an LLM Run my command through an LLM and tell me "don't do this" once, I'm out to a different distro :-). Also, if people copy-paste stuff they don't understand in a terminal (and running a script like this is pretty much "running stuff one does not understand"), I don't think there is anything you can do for them.
• deleted 1y ago
  [deleted]
• TZubiri 1y ago
  >curl -LsSf https://astral.sh/uv/install.sh https://astral.sh/uv/install.sh | sh Don't do this shit, especially if you were told to do this shit. If you are going to do this shit, separate the commands, read the bash script (and roll it down, if another file is downloaded, download that manually and inspect it). If you are going to ask people to do this shit, split the command into two. Someone that asks me to do something insecure is either a malicious actor that is trying to compromise me, or someone careless enough to be compromised themselves. I don't care what uv is, I can pip install stuff thank you. I install 2 or 3 things tops. I don't install 500 packages, that's sounds like a security nightmare. Change your ways or get pwned people. Don't go the way of node/npm p.s: Stop getting cute with your TLDs, use a .com or the TLD from your country, using gimmick TLDs is opaque and adds an unnecessary vector, in this case on the politics of the British Overseas Territory of Saint Helena, Ascension, and Tristan da Cunha.
  • monerozcash 1y ago
    Nobody actually inspects binaries anyway, what's the difference?
    • TZubiri 1y ago
      Why bother with python and open source then? Presumably every package you install with pip/uv would be source available and you could build them. The idea behind most package managers including apt and pip is that they help you build the software and try to make it easier for you without actually downloading and trusting binaries.
      • monerozcash 1y ago
        >Why bother with python and open source then? Because you can easily make changes to the software, not because it's way less likely to be backdoored. >The idea behind most package managers including apt and pip is that they help you build the software and try to make it easier for you without actually downloading and trusting binaries. I'm so deeply confused
• mogoh 1y ago
  Is it worth running uv inside a docker container?
  • hoherd 1y ago
    Sometimes, yes, but I would say it depends a lot on your base image and project. If nothing else, it gives you a runtime environment that is identical to your development environment. Using uv at build time can dramatically reduce your build times if you properly handle the uv cache. https://docs.astral.sh/uv/guides/integration/docker/#caching https://docs.astral.sh/uv/guides/integration/docker/#caching It's also easy: COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ https://docs.astral.sh/uv/guides/integration/docker https://docs.astral.sh/uv/guides/integration/docker
    • dirkc 1y ago
      If you are using it for your project, wouldn't you necessarily have to use it for your Docker setup as well?
• pixelbeat__ 1y ago
  It seems dotslash would complement uv well https://dotslash-cli.com/docs/ https://dotslash-cli.com/docs/ DotSlash to get the interpreter for your platform, and uv to get the dependencies. Perfect for corporate setups with custom mirrors etc.
• mov_dx_cx 1y ago
  After I just enjoying on python project nd actually built something.
• hexbin010 1y ago
  I predict it'll be the best and then the 'worst' thing: they'll go hard on monetisation. Just look at this post: 1839 points and 1048 comments! That is insane. It's captured the hearts and minds of Python devs and I'm sure they know it. I'm not against projects making money, just remember you'll likely pay a price later on once you invest in more of Astral's ecosystem. It's just temporarily free.
  • lijok 1y ago
    They’ve been very transparent about their monetization strategy and it does not impact uv’s foss model
    • hexbin010 1y ago
      That's just marketing. Only time will tell. I'll be very happy to be wrong
      • lijok 1y ago
        The time has come. They’re in closed beta with pyx, their first product they’re charging for.
        • maleldil 1y ago
          That assumes that pyx (or whatever else they come up with) will be enough to sustain the company.
          • lijok 1y ago
            Yes, as with every single OSS project in existence. If I write some OSS tool that becomes popular, and lose my job, I might just start monetizing it.
    • motbus3 1y ago
      Until they change their minds. If they were serious about it, it would be part of PyCQA
• Phelinofist 1y ago
  [project] name = "my_project" version = "1.0.0" requires-python = ">=3.9,<3.13" dependencies = [ "astropy>=5.0.0", "pandas>=1.0.0,<2.0", ] looks like a POM file
  • zahlman 1y ago
    This is an ecosystem-wide standard (the [project] table in pyproject.toml) and has nothing to do with uv specifically.
    • Phelinofist 1y ago
      My comment was actually tongue in cheek that the newest Python incarnation looks like the 20+ year old thing from Java, i.e. Python finally going in the right direction.
• amoe_ 1y ago
  If I'm already using Poetry and not facing any issues with it, is there any advantage to using uv?
  • tinodb 1y ago
    Speed. It's an order of magnitude faster, at least.
• rldjbpin 1y ago
  either conda is that old now or it seems a bit of a hyperbole. haven used it personally, uv is quite fast and nice to work with at first. definitely nice if you work in a team that fully utilise its potential. however, there felt a lot of parallels with the node.js universe and switching to .venv / localized environments bloats up the system when you work with a boilerplate env that is the same across projects. the additional files generated are also less human-readable compared to a requirements.txt and the workflow felt a bit more involved for individual users imho. it definitely has a place in the ecosystem, but personally don't find it ready to replace everything else yet.
• shevy-java 1y ago
  I am a bit skeptical. You only have to look at the ruby ecosystem and the recent mass-expulsion of long-term developers from rubygems/bundler via RubyCentral going full corporate-mode ("we needs us some more moneeeeeys now ... all for the community!!!" - or something). While one COULD find pros in everything, is what is happening in different programming languages really better for both users and developers? I am not quite convinced here. I am not saying the prior status quo was perfect. What I am saying is ... I am not quite convinced that the proposed benefits are real. In fact, I find managing multiple versions actually annoying. I should say that I already handle that via the GoboLinux way mostly (Name/Version/ going into a central directory; this is also similar what homebrew does, and also to some extent nixos, except that they store it via a unique hash which is less elegant. For instance, on GoboLinux I would then have /Programs/Ruby/3.3.0/ - that's about as simple as can possibly be). I really don't want a tool I don't understand to inject itself here and add more complications to that. My system is already quite simple and I don't really need anything it describes to me as "you need this". I also track and handle dependencies on my own. (This is more work to do initially, but past that point I just do "ue" on the commandline to update to the latest version, where ue is simply an alias to a ruby class called UpdateEntry, which in turn updates an entry in a .yml file, which then is used to populate a SQL database and also downloads and repackages and optionally compiles/installs the given package, e. g. "ue mesa" would just update mesa .tar.xz locally. I usually don't automatically compile it though, so "ue" I just use to update a program version or simply change it; it also accepts an URL of course so users can override this behaviour as they see fit.)
  • skywhopper 1y ago
    So you’ve learned one tool to handle this sort of complexity, but you are complaining that someone created a new one?
• randomsolutions 1y ago
  The only reason I haven't switched, is when using uv as my environment manager, starting/connecting to the python kernel in notebooks within vscode takes forever.
• frobisher 1y ago
  Would be nice to systematically start with problems of the non-uv world to highlight the specific value of uv. But nice read!
• bartdecrem 1y ago
  Should I try this? I, let’s say, code with Ai and am not an engineer. Python related environment stuff makes my head explode (across the 3 computers I use). It’s the main thing my brain just can’t seem to figure out.
  • fishmicrowaver 1y ago
    Well if you want to code with AI you'll have to tell claude/codex constantly that you're using uv and sometimes it'll remember.
    • nilamo 1y ago
      Or, you can use a task runner like mise or just, and tell it to use the task runner instead of any particular tool directly. `mise test:unit` is much harder for an agent to get wrong.
  • colpabar 1y ago
    Yes. This is currently the best tool to handle python environments and dependencies and it's very popular. If you learn uv, and you really don't need to learn that much other than how to specify a python version and your dependencies, you (hopefully) should be set for a long time.
  • bartdecrem 1y ago
    thanks y'all for the super helpful comments!
• varispeed 1y ago
  I don't know. This looks more complex than pyenv.
• jonnycomputer 1y ago
  I have to say that I am extremely reluctant to switch over to yet another python management system (packaging, environment, python version). Every few years someone says: this is it. Switch to poetry! Okay, I did. And, at least for some academic packages, psychopy I'm looking at you, it was a friggin disaster. so. will uv install psychopy (say version 3.2.4)?
  • pac0 1y ago
    This is it. Switch to uv! This time for real!
    • otabdeveloper4 1y ago
      It certainly isn't. See here: https://github.com/astral-sh/uv/issues/5190 https://github.com/astral-sh/uv/issues/5190 And here: https://pyproject-nix.github.io/uv2nix/FAQ.html#why-doesnt-uv2nix-come-with-overrides https://pyproject-nix.github.io/uv2nix/FAQ.html#why-doesnt-u...
      • zanie 1y ago
        You're upset that uv doesn't yet support something that no other tool in the ecosystem supports? I'd love for uv to lock build dependencies, but due to the dynamic nature of Python package metadata it's quite a hard problem. It'll be supported eventually though. (I work on uv)
        • otabdeveloper4 1y ago
          I'm just saying uv isn't "it", the packaging issue in Python isn't solved yet. And yes, build dependencies is the big elephant of why Python packaging sucks.
  • JodieBenitez 1y ago
    Well... I did pip -> poetry -> rye -> uv in less than a year, so I can understand the fatigue. But the fact is that uv is well above the rest and was well worth the effort (and the wait).
• mark_l_watson 1y ago
  UV lets me love using Python. There are other languages, mostly Lisp languages, that I have always liked better but my workflow with UV is so pleasant that I find myself not minding Python the language, even looking forward to using it. General comment: using Rust for utilities and libraries has revitalized Python.
  • oblio 1y ago
    Maybe Lisp could adopt these kinds of tools?
  • nonethewiser 1y ago
    The package management/ecosystem stuff has always been the worst part of using python. I learned on python and didn't realize how much of a broken mess this stuff was until I went to other languages. https://i.imgflip.com/aanifi.jpg https://i.imgflip.com/aanifi.jpg
• pidgeon_lover 1y ago
  > Can install any version of Python Does "any" version include custom homebrew builds of Python, e.g. backports of Python 3.12 to Windows Vista/7?
  • zbentley 1y ago
    No, uv installs pythons available from https://github.com/astral-sh/python-build-standalone https://github.com/astral-sh/python-build-standalone by default, which are quite good and have a wide variety of versions available, even on unusual platforms. If those don’t suit your needs, uv can be configured to use (and in some cases install or download, though that gets hairy) other versions you have installed yourself: https://docs.astral.sh/uv/concepts/python-versions/#managed-python-distributions https://docs.astral.sh/uv/concepts/python-versions/#managed-...
• dalf 1y ago
  This blog post was really helpful to understand the ecosystem: https://alpopkes.com/posts/python/packaging_tools/ https://alpopkes.com/posts/python/packaging_tools/ It mentions uv at the end and rye at first (which use uv internally).
• jelder 1y ago
  > On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers. Does that mean they aren't running unit tests _at all_ in CI yet, or they just use a totally different, newer system in production than they do for CI? Either way, brave of them to admit that in public.
  • bunderbunder 1y ago
    My team just did this. It wasn't anything like the radical change to how CI works that you seem to be envisioning. It was just deleting a lot of Python environment setup and management code that has a history of being obnoxious to maintain, and replacing it with a one-liner that, at least thus far, has given us zero fuss.
    • jelder 1y ago
      You updated _production_ before _testing_? Sorry but that just sounds like asking for a disaster.
      • bunderbunder 1y ago
        It seems like you're reading things that people aren't writing. I don't know how the author's company manages their stack, so I can't speak to how they do their testing. But I do know that in many companies run-time environment management in production is not owned by engineering and it's common for ops and developers to use different methods to install run-time dependencies in the CI environment and in the production environment. In companies that work that way, testing changes to the production runtime environment isn't done in CI; it's done in staging. If that's at all representative of how they work, then "we didn't test this with the automated tests that Engineering owns as part of their build" does not in any way imply, "we didn't test this at all." Tangentially, the place I worked that maintained the highest quality and availability standards (by far) did something like this, and it was a deliberate reliability engineering choice. They wanted a separate testing phase and runtime environment management policy that developers couldn't unilaterally control as part of a defense in depth strategy. Jamming everything into a vertically integrated, heavily automated CI/CD pipeline is also a valid choice, but one that has its roots in Silicon Valley culture, and therefore reaches different solutions to the same problems compared to what you might see in older industries and companies.
• thatsadude 1y ago
  Has been a life changer for me.
• Helmut10001 1y ago
  Does anyone know how Uv performs in the Geo-Package-Space? (i.e. GDAL, geopandas, cartopy, pyproj, rasterio etc.) This is the one area where I still find that conda performs best because all the authors of these packages use the conda-forge channel themselves for testing and production.
  • 12_throw_away 1y ago
    I believe the actual packaging technology is no different from pip - so if these packages don't install cleanly with `pip`, they won't install cleanly with `uv pip` either. If you need conda packages, uv isn't planning on supporting them [1]. [1] https://github.com/astral-sh/uv/issues/1703 https://github.com/astral-sh/uv/issues/1703
    • Helmut10001 1y ago
      Yes, there are several geopackages that will only work reliably with conda (GDAL, cartopy etc.), even under Linux.
• thomasvn 1y ago
  A great step forward for those who are already locked into the language! But IMO not necessarily encouragement for newcomers to start using the language for production software.
• thomspoon 1y ago
  I thoroughly enjoy uv, having used poetry and requirements.txt prior, but it does come with its faults in a large codebase. Admittedly, I don’t know whether they re due to uv’s infancy, or PEP restrictions. For example: 1. uv sync should update by default (like poetry) 2. uv lock revision and dependency resolver keep changing and it makes it hard to figure out if changes to our uv.lock are real or due to separate versions of uv among developers 3. uv pre-release dependency rules should be able to be disabled with either a sys_marker or specific case like pinning a version Some other pain points but I can’t remember them all at the top of my head..
• RoyTyrell 1y ago
  It's too bad they didn't call it something else besides uv given there's already other "uv" named tools like: uvicorn, uvloop, pyuv - and those three almost hvae more in common with each other than the uv build/project tool. Then there's also libuv.
• eclat 1y ago
  Seems to fulfill the same role as Bundler has done in Ruby for years.
• vanous 1y ago
  I love using uv and would be supper happy if it allowed me not only to add and remove uv add package uv remove package But also to upgrade a package and upgrade all packages in the pyproject.toml . The uv sync --upgrade can already do this in uv.lock , but not in pyproject.toml