10 ms·

Uv, a fast Python package and project manager

188 points by Loic 2y ago

kthejoker2 2y ago
Happy user so far in my early days ... appreciate the speed for sure
jamesblonde 2y ago
Super fast installs - when it works. I had problems on Ubuntu for linux (WSL) with a clang dependency, which i could never solve. But on linux boxes, it's so much better than pip/conda/etc. I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....'
- disgruntledphd2 2y ago
  > I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....' Huh cool, I'll have to try that. Conda is great for getting the dependencies for non python code (geos/gdal/cuda etc) but uv is super fast and straightforward (makes building packages much, much easier).
  - camel_Snake 2y ago
    same company has a different tool as well called pixi which aims for much nicer integration with the conda ecosystem. Also uses uv under the hood so speed is comparable. https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi
- mickeyp 2y ago
  So now you're using not one (conda); not two (conda and uv), but three (conda, uv and pip) different package managers to manage your Python environment?
  - dagw 2y ago
    "uv pip" is a ground up implementation of python pip and doesn't use the python pip command in any way. So still only two package managers. And the point is that you always have to use two package managers when developing python. One that installs python and various non-python libraries and dev tools, and one that installs python libraries. Conda in this scenario is replacing apt as much as anything else.
- claytonjy 2y ago
  Have you tried pixi? I haven’t, and i’m hoping i can continue to avoid conda, but it’s a uv-using conda replacement: https://pixi.sh/latest/ https://pixi.sh/latest/
pletnes 2y ago
I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is a massive improvement to the «getting started» problems in python.
- rollcat 2y ago
  Welcome to the bootstrapping problem. The original take is "how do I build a C compiler without a C compiler", and some amazingly gifted people from the GNU/Guix team managed to take it to its logical conclusion - and wrote a 357 byte piece of annotated machine code, from which an entire distro can be bootstrapped. On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. https://bootstrappable.org https://bootstrappable.org
  - wakawaka28 2y ago
    >On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. Thankfully the Python ecosystem probably isn't going to adopt this crazy Rust dependency. The Rust nuts are unbelievably and laughably persistent but this is an overcomplicated solution that nobody asked for. You could probably say the same about Rust in the Linux kernel so who knows...
    - rollcat 2y ago
joostlek 2y ago
Uv has been awesome so far. It brought the release time for Home Assistant down from an hour and a half to about 15 minutes. Also installing all the dependencies from scratch used to give you enough time to grab lunch and drink coffee, and now we can only grab the coffee in that time!
- nullify88 2y ago
  Unfortunately the implementation in HA also broke a lot of addons from HACS for many people running HA in a container.
  - delusional 2y ago
    Classic software problem. "This thing is so great, its never been faster. Now if only it didn't break everything for my users"
    - bdzr 2y ago
      An alternative framing. "This software could be so fast, but it's bogged down by having to support every single workflow it's ever once even accidentally supported."
      - fifilura 2y ago
        From the top of my head. * Microsoft Windows * Microsoft Excel * Python/Pandas * Web browsers They all do great things and deserve all the praise for maintaining backwards compatibility, havoc would have ensued otherwise. Does not mean that they should not be replaced though.
cinntaile 2y ago
Have they figured out yet how this VC backed company will make money? It's quite important imo, I don't want a watered down experience 5 years from now.
- qprofyeh 2y ago
  I would pay if they could make our GitHub CI run 20-30% faster.
- eddsolves 2y ago
  Pydantic had a nice model where the open source tool is fantastic, but they now sell a cloud based logging system around that. There will be some enterprise tooling around UV that they could sell while keeping the tool itself free
- the_mitsuhiko 2y ago
  Charlie is on record stating that their goal is to sell value added pieces to their tooling and keep the core tools free and open.
- bdzr 2y ago
  It sounds like they're not yet at the stage where they need to worry about it, though I've heard Charlie mention making an easy to host package registry as one offering.
Evidlo 2y ago
If I was the Python BDFL I would just merge this into pip and solve Python packaging forever. Only decisive action will fix package tooling fragmentation.
- dagw 2y ago
  People also said the same about poetry and pipevn (and no doubt some other tools I'm forgetting).
  - Evidlo 2y ago
    Neither of which became the canonical way of installing packages mostly because the Python Software Foundation does not want to endorse anything in particular.
- deleted 2y ago
  [deleted]
- aidos 2y ago
  Disagree. That seems like it would just slow down progress. Astral are winning mindshare because the tooling is so much better than the previous generations. That’s the action that’s required here - to be the compelling choice, rather than another choice that’s pretty much like the others and differs only a little.
- zahlman 2y ago
  It's worth remembering here the incident that led to Conda existing in the first place. There has never been a culture that would allow for this. And keep in mind that, aside from being a completely incompatible project, Pip is not part of the standard library. People don't agree that "package tooling fragmentation" is an actual problem, anyway. I'm one of them. The real problem is that a few of the basic tools (mainly, Pip and Setuptools) don't work properly. They have fundamental design flaws and are ridden with technical debt. The underlying implemented standards have also lagged behind, and Uv can't actually fix that. But once a solid base is established, I don't actually want to have a single tool making all the package management decisions for me. I want Unix-philosophy tools that handle specific individual development tasks, built around a proper, integrated user tool for installing applications and libraries (Pipx would be very close to such a tool, if it exposed its underlying Pip copy more elegantly and if Pip didn't suck). I don't want someone else's "project manager" to decide for me what build backend to use, or even to just bundle one. And I'm perfectly happy using `build` as a build frontend, `twine` as a PyPI uploader etc. Writing `uv upload` or whatever it actually uses, is not an improvement to me.
Raed667 2y ago
Does this still work if other devs on the project still use pyenv or other tools ?
- ilalex 2y ago
  Yep. You can gradually start to use feature set of uv. Beside it uses standards of python project management, so you don’t have vendor lock-in here.
- dagw 2y ago
  If they are using standard compliant tools like pyenv, venv and pip then uv will play nicely with that. In fact I'm working on a project like that right now. The 'official' guidelines says to use pip and venv, but I'm using uv and no one else notices. If on the other hand they're using a more optionated tool like poetry then it won't work as well, but that has more to do with poetry doing its own thing and not playing nice with other tools.
vegabook 2y ago
> poetry: 0.99 seconds Good enough for me and sans VC risk.
Kwpolska 2y ago
A VC-funded package and project manager for Python projects, written in Rust, and without involvement of the Python Packaging Authority (PyPA). If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether? Using Rust enables uv to install Python interpreters. That feature uses unofficial third-party binary builds. There are no official binary builds for Linux, but there are such builds for Windows and macOS, yet they use the unofficial third-party builds on those platforms as well. Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool (which may be the system package manager on some platforms).
- the_mitsuhiko 2y ago
  > without involvement of the Python Packaging Authority (PyPA) The PyPA does not really exist. The closest to an actual "authority" is the packaging forum on discuss.python.org and the astral folks are active there, see for instance the recent threads on the lockfile standard or the dynamic metadata issue. > If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether? People use Python, Astral exists to solve problems of Python people. I'm not sure what the language they are using to write the tool in is relevant. numpy, scipy, tensorflow and many other cornerstones of Python are written in C, C++ and other non Python languages. > but there are such builds for Windows and macOS As the author of Rye where I tried very much the same I can attest that the macOS builds are useless for the uv usecase. It's great that Astral is now maintaining the standalone builds which have become a cornerstone for many Python users over the last three years. We have based our entire development environments on those, even though we have not adopted either rye or uv at our company.
  - aragilar 2y ago
    I would argue Astral's products are in a substantively different category (developer tools) than numpy or scipy (numerical libraries), and the constraints on them are significantly different (e.g. like crypto code, you shouldn't roll your own numerical code, and instead use trustworthy libraries, which is what numpy/scipy wrap). Everything from their choice of language to which libraries to depend on (and which ones to make optional) to their installation system has been about being conservative and ensuring that the bootstrap process is as painless as possible for Python-only devs. Astral to me seem to be targeting a small subset of the community, and their ignorance of the needs outside of it make me very wary of adopting their tools.
These335 2y ago
I have only ever really used venv. Poetry was fine but didn't give me any additional benefits that I could see. What does this offer? And more broadly, why do people consider pip to be a problem? I have literally never had any issues with it in any of my projects.
- zahlman 2y ago
  > What does this offer? Referring to the entire category in general: mainly, it offers to keep track of what you've installed, and help you set up reproducible scripts to install the same set of dependencies. Depending on the specific tool, additional functionality can vary widely. (Which is part of why there's no standard: there's no agreement on what the additional functionality should be.) > why do people consider pip to be a problem? Many problems with Pip are really problems with the underlying packaging standards. But Pip introduces a lot of its own problems as well: * For years, everyone was expected to use a workflow whereby Pip is copied into each new venv (this is surprisingly slow - over 3 seconds on my machine); users have accidentally invented a million different ways (mainly platform-specific) for `pip` to refer to a different environment than `python` does, causing confusion. (For a while, Setuptools was also copied in by default and now it isn't any more, causing more confusion.) You don't need to do this - since 22.3, Pip has improved support for installing cross-environment, and IMX it Just Works - but people don't seem to know about it. * Pip builds projects from sdists (thereby potentially running arbitrary code, before the user has had a chance to inspect anything - which is why this is much worse than the fact that the library itself is arbitrary code that you'll import and use later) with very little provocation. It even does this when you explicitly ask it just to download a package without installing it; and it does so in order to verify metadata (i.e., to check that building the sdist would result in an installable wheel with the right name and version). There's wide consensus that it doesn't really need to do this, but the internals aren't designed to make it an easy fix. I have an entire blog post in my planned pipeline about just this issue. * Pip's algorithm for resolving package dependencies is thorough at the cost of speed. Depending on the kind of packages you use, it will often download multiple versions of a package as sdists, build them, check the resulting metadata, discover that this version isn't usable (either it doesn't satisfy something else's requirement, or its own requirements are incompatible) and try again. (This is partly due to how Python's import system, itself, works; you can't properly support multiple versions of the same library in the same environment, because the `import` syntax doesn't give you a clean way to specify which one you want.) * Because of how the metadata works, you can't retroactively patch up your metadata for old published versions because e.g. you found out that you've been using something that's deprecated in the new Python release. This has especially bad interactions with the previous point in some cases and explaining it is beyond the scope of a post here; see for example https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ for a proper explanation. But the main reason why you'd use a package manager rather than directly working with Pip, is that Pip is only installing the packages, not, well, managing them. Pip has some record of which packages depend on which others, but it won't "garbage-collect" for you - if something was installed indirectly as a dependency, and then everything that depends on it is removed, the dependency is still there. Further, trying to upgrade stuff could, to my understanding, cause breakages if the dependency situation is complex enough. And above all of that, you're on your own for remembering why you installed any given thing into the current environment, or figuring out whether it's still needed. Which is important if you want to distribute your code, without expecting your users to recreate your entire environment (which might contain irrelevant things).
the_mitsuhiko 2y ago
Since the topic of VC funding keeps coming up, I will quote myself from the blog post I did a few months ago [1]: > there is an elephant in the room which is that Astral is a VC funded company. What does that mean for the future of these tools? Here is my take on this: for the community having someone pour money into it can create some challenges. For the PSF and the core Python project this is something that should be considered. However having seen the code and what uv is doing, even in the worst possible future this is a very forkable and maintainable thing. I believe that even in case Astral shuts down or were to do something incredibly dodgy licensing wise, the community would be better off than before uv existed. [1]: https://lucumr.pocoo.org/2024/8/21/harvest-season/ https://lucumr.pocoo.org/2024/8/21/harvest-season/
- thangngoc89 2y ago
  But uv is written in Rust so it means there are considerably more efforts to fork it as compared to Python tools
  - schubart 2y ago
    How so?
    - globalnode 2y ago
      I think they must mean that the number of rust developers would be small compared to the number of python developers. Perhaps? Not sure myself.
      - nsteel 2y ago
        I think people need to appreciate that the number of developers interested in actually helping with free software maintenance is a subset of the number of developers. And when it comes to Python in particular, that subset is proportionally very small. That's just my anecdotal experience of similar projects in both ecosystems.
      - hobofan 2y ago
short_sells_poo 2y ago
So, why should I switch to this and what is going to stop some other tool becoming the "python package/env management darling" in 2025?
- ilalex 2y ago
  Have you tried ruff for linting? If you have joy of using it, you should try uv. It’s the same feeling
- thangngoc89 2y ago
  I switched to uv recently from poetry because uv manages the python version too.
- sswatson 2y ago
  The way I feel is that if another tool comes along that I like better, I’ll switch again. Or if I prefer the stability for some reason, I won’t. Either way, I don’t see any need to stop people from building better things.
bruh2 2y ago
UV creator's response on the concerns regarding VC money: > I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models). > 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 (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...] > But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS. https://hachyderm.io/@charliermarsh/113103564055291456 https://hachyderm.io/@charliermarsh/113103564055291456
- blitzar 2y ago
  Prior art. > Facebook's mission is to give people the power to build community and bring the world closer together. > Our informal corporate motto is "Don't be evil." We Googlers generally relate those words to the way we serve our users – as well we should. But being "a different kind of company" means more than the products we make and the business we're building; it means making sure that our core values inform our conduct in all aspects of our lives as Google employees. > OpenAi.
- deleted 2y ago
  [deleted]
- walthamstow 2y ago
  'I don't want to' is very different to 'I will never'
em70 2y ago
Pixi is just better.
- thangngoc89 2y ago
  Pixi uses uv solver too but more focused on integrating with the conda packaging world
outlore 2y ago
Things i love about uv/astral - Putting .venv automatically into the project directory - Installing dependencies with pyproject.toml - Installing any Python version - Fast pip installs - uvx (like npx) - Ruff formatter and linter, made by the same people Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv
- wiseowise 2y ago
  I concur. Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.
  - mickeyp 2y ago
    As opposed to: `python3 -m pip install <package>' to install it? And `python3 -m <package>' to run it?
    - wiseowise 2y ago
      You forgot to initialize venv and activate it. And now also do it on other dev's machine shared via git.
      - mickeyp 2y ago
        They are one-offs, much like your init command. You do not have to activate it: you can explicitly invoke the binary in the venv if you do not want this.
        wiseowise 2y ago
        I spawn dozens of one-offs, cost adds up. Some of those evolve to not be one-offs, and then synchronization with other devs becomes a problem.
throw646577 2y ago
The answer to the question about VC funding is weirdly obvious at any sort of distance away from the emotive things. Communities should probably cautiously welcome VC funding for well-integrated community members solving hard, core problems with correctly-licensed contributions back to the community, as long as that effort doesn't divert community engineering focus away from long-term community goals and towards the startup's goals in non-beneficial way. They should be more cynical about things that don't happen this way, but then they can keep doing their own thing anyway. Ondsel found the money for two major core technical problems to be addressed in FreeCAD, and seems to have had a pretty positive impact on release-oriented thinking in general. They then folded. It is a loss, but essentially none of the work was lost. Frankly I am not sure if the "written in Rust" element here is culturally beneficial in the long term or not; I don't know enough about Python or really anything about Rust.
zelphirkalt 2y ago
Not quite sure what kind of projects people are talking about here, where Poetry takes too long. Must be pretty massive sets of dependencies. Maybe huuuge monoliths? What I usually do is build a venv in a docker container of a service and then that gets deployed. I don't see a problem, if this took a minute or two, but so far it never did take that long.
- movpasd 2y ago
  I'd say there are two things that make me prefer rye/uv. The speed is one — sometimes I'm in the middle of a project and realise I need to pull in another dependency. Keeping the disruption to flow at a minimum is helpful in those cases. So it's not about deployed performance, it's about mental friction. The other is I've found Poetry liable to breaking in obscure ways. I don't fully control everything on my work machine, which I suspect is the issue. So far, rye and uv have been smooth, but that might be down to me not having used them long enough.
- Leynos 2y ago
  Yes, huge monoliths
- dist-epoch 2y ago
  If you do anything ML or neural networks, suddenly you have hundreds of packages totaling over 1 GB.
andrewinardeer 2y ago
Please give me commands to create a virtual environment built with libraries listed in the requirements.txt of a GitHub repo. Ubuntu here.
- zanie 2y ago
  e.g. $ uv venv Using CPython 3.12.6 Creating virtual environment at: .venv Activate with: source .venv/bin/activate $ uv pip install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt Resolved 43 packages in 283ms Prepared 4 packages in 64ms Installed 43 packages in 445ms ...
- zahlman 2y ago
  For comparison, with bare-bones tools (assuming `pip` is a globally-visible Pip version 22.3[0] or better): $ python -m venv --without-pip .venv $ pip --python .venv/bin/python install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt This venv creation is instantaneous, because it doesn't install Pip in the new venv. On my 10-year-old machine, with cached packages (it still has to unzip everything and move it around), the installation takes about 8.5 seconds. I have some wrapper scripts defined locally to smooth out this process; I can do `make-project-venv` (which puts the venv in `.local/.venv` and also attempts to install the current project with `pip --python ... install -e .`) and then `activate-local` and then `pipe install ...`. [0]: https://pip.pypa.io/en/stable/news/#v22-3 https://pip.pypa.io/en/stable/news/#v22-3
Jasondells 2y ago
uv is cool, no doubt—super fast, love the idea of managing Python versions + deps all in one place. But VC funding... Rust... unofficial Python builds... lots of red flags here if you think about the long-term impact on the ecosystem. VC-backed tools always make me a little nervous. Sure, Astral says the tools will stay free, and I get that they're targeting enterprise for revenue (private package registries, etc.). But how many times have we heard this before? “Don’t be evil,” right? We’ve seen companies pivot to paywalls or watered-down open-source tools after funding dries up. What guarantees do we have here that uv won't eventually fall into that same trap? Yeah, Rust is amazing (ruff is a beast), but it’s still a small subset of devs compared to Python. If Astral folds or just loses interest, how easy is this really going to be for the Python community to maintain? Forkable? Sure. But forkable ≠ maintainable when the dev pool is tiny. Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries? And fragmentation... Python tooling is already a mess. Pip, poetry, conda, pyenv, rye, flit, etc.—do we really need another tool in the mix? Feels like every new tool just promises to "fix packaging forever" but ends up adding another layer of complexity. Why not contribute these improvements to existing tools like pip? Sure, innovation is great, but at what point does it become too much choice and not enough cohesion? uv looks great, and I love the speed + features. But the ecosystem-level risks here... hard to ignore. Would love to see some stronger guarantees around open-source sustainability, community governance, and alignment with Python standards before jumping in fully. Otherwise, it’s just one more shiny tool that could end up abandoned or locked behind a paywall in 5 years.
- dist-epoch 2y ago
  > unofficial Python builds You don't need to use those, works perfectly fine with whatever Python is on the machine.
- jdxcode 2y ago
  > Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries? The official macOS binaries wouldn't work for uv because they're not portable. They're also taking ownership over the indygreg project which is a great thing for everyone since portable pythons are useful in a lot of contexts. I'm sure they'll start sending some of the portability changes upstream too once they get there. I don't see how this is criticism.
benreesman 2y ago
Using `uv` for Python is the first time I have used Python and enjoyed the experience full stop. `ruff` is also just straight up amazing. Everything else should do us all a favor and deprecate itself tomorrow.
deleted 2y ago
[deleted]
TeMPOraL 2y ago
Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. Between this and other tooling from that same company, it feels to me that, in the space of less than a year, Python has turned from a community language into a company-led one (like. e.g. Scala). Not saying whether it's good or bad - just that it's damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I'd love to understand how did this happen. -- [0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash. [1] - Anyone remembers libuv? Spearheading the whole async/await paradigm by powering it in Node.JS, it's one of the most known and talked about libraries ever.
- dist-epoch 2y ago
  Because uv is excellent in some ways and good in all ways. Pretty much all other package managers suck in some way. > confusingly named The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. > Python has turned from a community language into a company-led one That's quite a radical take, reducing a language to it's package manager and linter. > backed by a for-profit company so is VS Code
  - TeMPOraL 2y ago
    > The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. So? 3 letters isn't some magic cutoff; cutting your command down to 3 letters or less doesn't make it suddenly 10x more effective for its users. 4 or 5 letters would be fine, too. > That's quite a radical take, reducing a language to it's package manager and linter. Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation. The trend in the last couple decades is to, in fact, make all three part of the core, under purview of the same person or group that designs the language itself, and its standard library. I.e. if you want to "own" the future of a language, the second best option after owning the most popular runtime, is to own the most popular package manager. And I can see this happening already in discussion threads about Python I've been reading over past few months. It's not just that people are excited about UV itself, they're treating Astral as a "thought leader" now. Again, I'm not saying it's bad, or that Astral would be a bad steward. I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. > so is VS Code VS Code is its own thing; sure, it sucked oxygen out of IDE space on UI front, but it also competes against JetBrains in the same space, plus, thanks to LSP, it revitalized Vim and Emacs as viable competitors and enabled creation of even more editors. In contrast, UV just put a single company in the core position to influence the direction Python as a language takes, which is a new situation for Python - one of the last few popular languages that didn't have a corporate benefactor to start and push it into popularity.
greatgib 2y ago
For me it is not great because of the new requirement for "rust" for basic Python. Does not make any sense. Especially if the main selling point is "speed". I never encounter cases where the pip install equivalent was particularly unbearably long except in very badly designed and broken projects. The kind of one that that import every possible dependency (nom style) with pinning things on broken and incompatible set of dependencies... Also, I like very much the concept of one tool for one usage. And having venv and pip is great, having one tool cluster mixing everything is not. Sure in most dummy usage cases it will be great, but you have more chance of clusterfucks and complicated unresolvable issues. Even more if developers are opinionated on a single way to do something.
- the_mitsuhiko 2y ago
  > For me it is not great because of the new requirement for "rust" for basic Python. Does not make any sense. The language of choice for such core functionality in the past was C. I'm not sure how much spelunking you did in the core interpreter, but the Astral rust code is much easier to understand and modify.
  - greatgib 2y ago
    But C did not disappear, now you need C and Rust. If Python was based on Rust, I guess I would not mind, but it is not. Also C is also supported everywhere! And personally I don't see why Rust would be more easy to understand than C. C is really straightforward compared to Rust. All of that being said, for something as basic and important as a package manager I would except that it is implemented in pure Python so it might easily be hack, modified or fixed without requiring any compilation... Like most of pip and setup tools were. Just wait for the moment that you can't update some libraries in your code because UV will not work without being updated, but an updated version binary is not available or you need to fix/backport something, so you need to build it. But unfortunately rust devs will not care supported older systems/os, so you are fucked. And you need to upgrade your whole system just to be able to update a simple application library.
eternityforest 2y ago
Is there any way to make wheels with pinned dependencies with this? That's the main thing keeping me with Poetry. Other than that I'm super excited.
- zanie 2y ago
  Not yet! We're thinking about it but it's hard to do in a spec-compliant way.
  - zahlman 2y ago
    What actually would be the hiccup there? Can't you just edit pyproject.toml and add the pinned transitive dependencies to [project.dependencies], and let a build backend take it from there? That's the extent of the pinning that the wheel format supports, anyway, as far as I understand.
    - eternityforest 2y ago
      Kind of hacktastic but I guess you could make an external tool that backs up pyproject.toml, sets it to have whatever is installed in the .venv as pinned dependencies, builds the wheel, then restored the old file. Seems like the kind of thing that might have some kind of edge case somewhere I'm not thinking of at the moment though.
      - zahlman 2y ago
        >Seems like the kind of thing that might have some kind of edge case somewhere I'm not thinking of at the moment though. It wouldn't support hashes, or anything else that you can't do with ordinary dependency specifiers in the project.dependencies list (spec: https://peps.python.org/pep-0508/ https://peps.python.org/pep-0508/).
Techtsunami 2y ago
I have noticed a spike in attention to UV since Anthropic announced the Model Context Protocol (MCP). After using it for MCP development, I am moving from pyenv to uv! https://www.anthropic.com/news/model-context-protocol https://www.anthropic.com/news/model-context-protocol
kkfx 2y ago
Honestly? It's excellent but it's Python only, I dream a day where NixOS/Guix Systems will be so common that anybody will use their approach to develop in any language (and the future Nix is something more digestible and Guix system will care more about the desktop, as side dreams)...

188 points by Loic 2y ago

Happy user so far in my early days ... appreciate the speed for sure

Super fast installs - when it works. I had problems on Ubuntu for linux (WSL) with a clang dependency, which i could never solve. But on linux boxes, it's so much better than pip/conda/etc. I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....'

disgruntledphd2 2y ago
> I also like that i can use it with conda environments. Just create conda env, then install with 'uv pip install ....' Huh cool, I'll have to try that. Conda is great for getting the dependencies for non python code (geos/gdal/cuda etc) but uv is super fast and straightforward (makes building packages much, much easier).
- camel_Snake 2y ago
  same company has a different tool as well called pixi which aims for much nicer integration with the conda ecosystem. Also uses uv under the hood so speed is comparable. https://github.com/prefix-dev/pixi https://github.com/prefix-dev/pixi
mickeyp 2y ago
So now you're using not one (conda); not two (conda and uv), but three (conda, uv and pip) different package managers to manage your Python environment?
- dagw 2y ago
  "uv pip" is a ground up implementation of python pip and doesn't use the python pip command in any way. So still only two package managers. And the point is that you always have to use two package managers when developing python. One that installs python and various non-python libraries and dev tools, and one that installs python libraries. Conda in this scenario is replacing apt as much as anything else.
claytonjy 2y ago
Have you tried pixi? I haven’t, and i’m hoping i can continue to avoid conda, but it’s a uv-using conda replacement: https://pixi.sh/latest/ https://pixi.sh/latest/

pletnes 2y ago

I’ve been missing a python tool like this that isn’t written in python. Conda was good in this regard - having a distribution without first installing python is a massive improvement to the «getting started» problems in python.

rollcat 2y ago
Welcome to the bootstrapping problem. The original take is "how do I build a C compiler without a C compiler", and some amazingly gifted people from the GNU/Guix team managed to take it to its logical conclusion - and wrote a 357 byte piece of annotated machine code, from which an entire distro can be bootstrapped. On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. https://bootstrappable.org https://bootstrappable.org
- wakawaka28 2y ago
  >On the bright side, uv is written in Rust, which makes distributing prebuilt releases practical, and helps end-users getting started. OTOH Linux+GNU+GCC pale in comparison to Rust's own bootstrapping problem - each Rust compiler is written in some previous release/dialect of Rust, all the way back to the pre-1.0 days, when it was written in an obscure dialect of OCaml. There are efforts underway to make Rust bootstrappable, but as of right now the Python ecosystem might be painting itself into a corner with slowly making Rust a hard dependency. Thankfully the Python ecosystem probably isn't going to adopt this crazy Rust dependency. The Rust nuts are unbelievably and laughably persistent but this is an overcomplicated solution that nobody asked for. You could probably say the same about Rust in the Linux kernel so who knows...
  - rollcat 2y ago

joostlek 2y ago

Uv has been awesome so far. It brought the release time for Home Assistant down from an hour and a half to about 15 minutes. Also installing all the dependencies from scratch used to give you enough time to grab lunch and drink coffee, and now we can only grab the coffee in that time!

nullify88 2y ago
Unfortunately the implementation in HA also broke a lot of addons from HACS for many people running HA in a container.
- delusional 2y ago
  Classic software problem. "This thing is so great, its never been faster. Now if only it didn't break everything for my users"
  - bdzr 2y ago
    An alternative framing. "This software could be so fast, but it's bogged down by having to support every single workflow it's ever once even accidentally supported."
    - fifilura 2y ago
      From the top of my head. * Microsoft Windows * Microsoft Excel * Python/Pandas * Web browsers They all do great things and deserve all the praise for maintaining backwards compatibility, havoc would have ensued otherwise. Does not mean that they should not be replaced though.

cinntaile 2y ago

Have they figured out yet how this VC backed company will make money? It's quite important imo, I don't want a watered down experience 5 years from now.

qprofyeh 2y ago
I would pay if they could make our GitHub CI run 20-30% faster.
eddsolves 2y ago
Pydantic had a nice model where the open source tool is fantastic, but they now sell a cloud based logging system around that. There will be some enterprise tooling around UV that they could sell while keeping the tool itself free
the_mitsuhiko 2y ago
Charlie is on record stating that their goal is to sell value added pieces to their tooling and keep the core tools free and open.
bdzr 2y ago
It sounds like they're not yet at the stage where they need to worry about it, though I've heard Charlie mention making an easy to host package registry as one offering.

Evidlo 2y ago

If I was the Python BDFL I would just merge this into pip and solve Python packaging forever. Only decisive action will fix package tooling fragmentation.

dagw 2y ago
People also said the same about poetry and pipevn (and no doubt some other tools I'm forgetting).
- Evidlo 2y ago
  Neither of which became the canonical way of installing packages mostly because the Python Software Foundation does not want to endorse anything in particular.
deleted 2y ago
[deleted]
aidos 2y ago
Disagree. That seems like it would just slow down progress. Astral are winning mindshare because the tooling is so much better than the previous generations. That’s the action that’s required here - to be the compelling choice, rather than another choice that’s pretty much like the others and differs only a little.
zahlman 2y ago
It's worth remembering here the incident that led to Conda existing in the first place. There has never been a culture that would allow for this. And keep in mind that, aside from being a completely incompatible project, Pip is not part of the standard library. People don't agree that "package tooling fragmentation" is an actual problem, anyway. I'm one of them. The real problem is that a few of the basic tools (mainly, Pip and Setuptools) don't work properly. They have fundamental design flaws and are ridden with technical debt. The underlying implemented standards have also lagged behind, and Uv can't actually fix that. But once a solid base is established, I don't actually want to have a single tool making all the package management decisions for me. I want Unix-philosophy tools that handle specific individual development tasks, built around a proper, integrated user tool for installing applications and libraries (Pipx would be very close to such a tool, if it exposed its underlying Pip copy more elegantly and if Pip didn't suck). I don't want someone else's "project manager" to decide for me what build backend to use, or even to just bundle one. And I'm perfectly happy using `build` as a build frontend, `twine` as a PyPI uploader etc. Writing `uv upload` or whatever it actually uses, is not an improvement to me.

Raed667 2y ago

Does this still work if other devs on the project still use pyenv or other tools ?

ilalex 2y ago
Yep. You can gradually start to use feature set of uv. Beside it uses standards of python project management, so you don’t have vendor lock-in here.
dagw 2y ago
If they are using standard compliant tools like pyenv, venv and pip then uv will play nicely with that. In fact I'm working on a project like that right now. The 'official' guidelines says to use pip and venv, but I'm using uv and no one else notices. If on the other hand they're using a more optionated tool like poetry then it won't work as well, but that has more to do with poetry doing its own thing and not playing nice with other tools.

vegabook 2y ago

> poetry: 0.99 seconds Good enough for me and sans VC risk.

Kwpolska 2y ago

A VC-funded package and project manager for Python projects, written in Rust, and without involvement of the Python Packaging Authority (PyPA). If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether? Using Rust enables uv to install Python interpreters. That feature uses unofficial third-party binary builds. There are no official binary builds for Linux, but there are such builds for Windows and macOS, yet they use the unofficial third-party builds on those platforms as well. Still, I would consider package and project management to be a separate feature from Python management, and I’d leave it to a different tool (which may be the system package manager on some platforms).

the_mitsuhiko 2y ago
> without involvement of the Python Packaging Authority (PyPA) The PyPA does not really exist. The closest to an actual "authority" is the packaging forum on discuss.python.org and the astral folks are active there, see for instance the recent threads on the lockfile standard or the dynamic metadata issue. > If Python is too slow or otherwise not good enough to write a good Python package manager in, why use Python altogether? People use Python, Astral exists to solve problems of Python people. I'm not sure what the language they are using to write the tool in is relevant. numpy, scipy, tensorflow and many other cornerstones of Python are written in C, C++ and other non Python languages. > but there are such builds for Windows and macOS As the author of Rye where I tried very much the same I can attest that the macOS builds are useless for the uv usecase. It's great that Astral is now maintaining the standalone builds which have become a cornerstone for many Python users over the last three years. We have based our entire development environments on those, even though we have not adopted either rye or uv at our company.
- aragilar 2y ago
  I would argue Astral's products are in a substantively different category (developer tools) than numpy or scipy (numerical libraries), and the constraints on them are significantly different (e.g. like crypto code, you shouldn't roll your own numerical code, and instead use trustworthy libraries, which is what numpy/scipy wrap). Everything from their choice of language to which libraries to depend on (and which ones to make optional) to their installation system has been about being conservative and ensuring that the bootstrap process is as painless as possible for Python-only devs. Astral to me seem to be targeting a small subset of the community, and their ignorance of the needs outside of it make me very wary of adopting their tools.

These335 2y ago

I have only ever really used venv. Poetry was fine but didn't give me any additional benefits that I could see. What does this offer? And more broadly, why do people consider pip to be a problem? I have literally never had any issues with it in any of my projects.

zahlman 2y ago
> What does this offer? Referring to the entire category in general: mainly, it offers to keep track of what you've installed, and help you set up reproducible scripts to install the same set of dependencies. Depending on the specific tool, additional functionality can vary widely. (Which is part of why there's no standard: there's no agreement on what the additional functionality should be.) > why do people consider pip to be a problem? Many problems with Pip are really problems with the underlying packaging standards. But Pip introduces a lot of its own problems as well: * For years, everyone was expected to use a workflow whereby Pip is copied into each new venv (this is surprisingly slow - over 3 seconds on my machine); users have accidentally invented a million different ways (mainly platform-specific) for `pip` to refer to a different environment than `python` does, causing confusion. (For a while, Setuptools was also copied in by default and now it isn't any more, causing more confusion.) You don't need to do this - since 22.3, Pip has improved support for installing cross-environment, and IMX it Just Works - but people don't seem to know about it. * Pip builds projects from sdists (thereby potentially running arbitrary code, before the user has had a chance to inspect anything - which is why this is much worse than the fact that the library itself is arbitrary code that you'll import and use later) with very little provocation. It even does this when you explicitly ask it just to download a package without installing it; and it does so in order to verify metadata (i.e., to check that building the sdist would result in an installable wheel with the right name and version). There's wide consensus that it doesn't really need to do this, but the internals aren't designed to make it an easy fix. I have an entire blog post in my planned pipeline about just this issue. * Pip's algorithm for resolving package dependencies is thorough at the cost of speed. Depending on the kind of packages you use, it will often download multiple versions of a package as sdists, build them, check the resulting metadata, discover that this version isn't usable (either it doesn't satisfy something else's requirement, or its own requirements are incompatible) and try again. (This is partly due to how Python's import system, itself, works; you can't properly support multiple versions of the same library in the same environment, because the `import` syntax doesn't give you a clean way to specify which one you want.) * Because of how the metadata works, you can't retroactively patch up your metadata for old published versions because e.g. you found out that you've been using something that's deprecated in the new Python release. This has especially bad interactions with the previous point in some cases and explaining it is beyond the scope of a post here; see for example https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ for a proper explanation. But the main reason why you'd use a package manager rather than directly working with Pip, is that Pip is only installing the packages, not, well, managing them. Pip has some record of which packages depend on which others, but it won't "garbage-collect" for you - if something was installed indirectly as a dependency, and then everything that depends on it is removed, the dependency is still there. Further, trying to upgrade stuff could, to my understanding, cause breakages if the dependency situation is complex enough. And above all of that, you're on your own for remembering why you installed any given thing into the current environment, or figuring out whether it's still needed. Which is important if you want to distribute your code, without expecting your users to recreate your entire environment (which might contain irrelevant things).

the_mitsuhiko 2y ago

Since the topic of VC funding keeps coming up, I will quote myself from the blog post I did a few months ago [1]: > there is an elephant in the room which is that Astral is a VC funded company. What does that mean for the future of these tools? Here is my take on this: for the community having someone pour money into it can create some challenges. For the PSF and the core Python project this is something that should be considered. However having seen the code and what uv is doing, even in the worst possible future this is a very forkable and maintainable thing. I believe that even in case Astral shuts down or were to do something incredibly dodgy licensing wise, the community would be better off than before uv existed. [1]: https://lucumr.pocoo.org/2024/8/21/harvest-season/ https://lucumr.pocoo.org/2024/8/21/harvest-season/

thangngoc89 2y ago
But uv is written in Rust so it means there are considerably more efforts to fork it as compared to Python tools
- schubart 2y ago
  How so?
  - globalnode 2y ago
    I think they must mean that the number of rust developers would be small compared to the number of python developers. Perhaps? Not sure myself.
    - nsteel 2y ago
      I think people need to appreciate that the number of developers interested in actually helping with free software maintenance is a subset of the number of developers. And when it comes to Python in particular, that subset is proportionally very small. That's just my anecdotal experience of similar projects in both ecosystems.
    - hobofan 2y ago

short_sells_poo 2y ago

So, why should I switch to this and what is going to stop some other tool becoming the "python package/env management darling" in 2025?

ilalex 2y ago
Have you tried ruff for linting? If you have joy of using it, you should try uv. It’s the same feeling
thangngoc89 2y ago
I switched to uv recently from poetry because uv manages the python version too.
sswatson 2y ago
The way I feel is that if another tool comes along that I like better, I’ll switch again. Or if I prefer the stability for some reason, I won’t. Either way, I don’t see any need to stop people from building better things.

bruh2 2y ago

UV creator's response on the concerns regarding VC money: > I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models). > 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 (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...] > But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS. https://hachyderm.io/@charliermarsh/113103564055291456 https://hachyderm.io/@charliermarsh/113103564055291456

blitzar 2y ago
Prior art. > Facebook's mission is to give people the power to build community and bring the world closer together. > Our informal corporate motto is "Don't be evil." We Googlers generally relate those words to the way we serve our users – as well we should. But being "a different kind of company" means more than the products we make and the business we're building; it means making sure that our core values inform our conduct in all aspects of our lives as Google employees. > OpenAi.
deleted 2y ago
[deleted]
walthamstow 2y ago
'I don't want to' is very different to 'I will never'

em70 2y ago

Pixi is just better.

thangngoc89 2y ago
Pixi uses uv solver too but more focused on integrating with the conda packaging world

outlore 2y ago

Things i love about uv/astral - Putting .venv automatically into the project directory - Installing dependencies with pyproject.toml - Installing any Python version - Fast pip installs - uvx (like npx) - Ruff formatter and linter, made by the same people Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv

wiseowise 2y ago
I concur. Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.
- mickeyp 2y ago
  As opposed to: `python3 -m pip install <package>' to install it? And `python3 -m <package>' to run it?
  - wiseowise 2y ago
    You forgot to initialize venv and activate it. And now also do it on other dev's machine shared via git.
    - mickeyp 2y ago
      They are one-offs, much like your init command. You do not have to activate it: you can explicitly invoke the binary in the venv if you do not want this.
      - wiseowise 2y ago
        I spawn dozens of one-offs, cost adds up. Some of those evolve to not be one-offs, and then synchronization with other devs becomes a problem.

throw646577 2y ago

The answer to the question about VC funding is weirdly obvious at any sort of distance away from the emotive things. Communities should probably cautiously welcome VC funding for well-integrated community members solving hard, core problems with correctly-licensed contributions back to the community, as long as that effort doesn't divert community engineering focus away from long-term community goals and towards the startup's goals in non-beneficial way. They should be more cynical about things that don't happen this way, but then they can keep doing their own thing anyway. Ondsel found the money for two major core technical problems to be addressed in FreeCAD, and seems to have had a pretty positive impact on release-oriented thinking in general. They then folded. It is a loss, but essentially none of the work was lost. Frankly I am not sure if the "written in Rust" element here is culturally beneficial in the long term or not; I don't know enough about Python or really anything about Rust.

zelphirkalt 2y ago

Not quite sure what kind of projects people are talking about here, where Poetry takes too long. Must be pretty massive sets of dependencies. Maybe huuuge monoliths? What I usually do is build a venv in a docker container of a service and then that gets deployed. I don't see a problem, if this took a minute or two, but so far it never did take that long.

movpasd 2y ago
I'd say there are two things that make me prefer rye/uv. The speed is one — sometimes I'm in the middle of a project and realise I need to pull in another dependency. Keeping the disruption to flow at a minimum is helpful in those cases. So it's not about deployed performance, it's about mental friction. The other is I've found Poetry liable to breaking in obscure ways. I don't fully control everything on my work machine, which I suspect is the issue. So far, rye and uv have been smooth, but that might be down to me not having used them long enough.
Leynos 2y ago
Yes, huge monoliths
dist-epoch 2y ago
If you do anything ML or neural networks, suddenly you have hundreds of packages totaling over 1 GB.

andrewinardeer 2y ago

Please give me commands to create a virtual environment built with libraries listed in the requirements.txt of a GitHub repo. Ubuntu here.

zanie 2y ago
e.g. $ uv venv Using CPython 3.12.6 Creating virtual environment at: .venv Activate with: source .venv/bin/activate $ uv pip install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt Resolved 43 packages in 283ms Prepared 4 packages in 64ms Installed 43 packages in 445ms ...
zahlman 2y ago
For comparison, with bare-bones tools (assuming `pip` is a globally-visible Pip version 22.3[0] or better): $ python -m venv --without-pip .venv $ pip --python .venv/bin/python install -r https://raw.githubusercontent.com/astral-sh/uv/refs/heads/main/docs/requirements.txt This venv creation is instantaneous, because it doesn't install Pip in the new venv. On my 10-year-old machine, with cached packages (it still has to unzip everything and move it around), the installation takes about 8.5 seconds. I have some wrapper scripts defined locally to smooth out this process; I can do `make-project-venv` (which puts the venv in `.local/.venv` and also attempts to install the current project with `pip --python ... install -e .`) and then `activate-local` and then `pipe install ...`. [0]: https://pip.pypa.io/en/stable/news/#v22-3 https://pip.pypa.io/en/stable/news/#v22-3

Jasondells 2y ago

uv is cool, no doubt—super fast, love the idea of managing Python versions + deps all in one place. But VC funding... Rust... unofficial Python builds... lots of red flags here if you think about the long-term impact on the ecosystem. VC-backed tools always make me a little nervous. Sure, Astral says the tools will stay free, and I get that they're targeting enterprise for revenue (private package registries, etc.). But how many times have we heard this before? “Don’t be evil,” right? We’ve seen companies pivot to paywalls or watered-down open-source tools after funding dries up. What guarantees do we have here that uv won't eventually fall into that same trap? Yeah, Rust is amazing (ruff is a beast), but it’s still a small subset of devs compared to Python. If Astral folds or just loses interest, how easy is this really going to be for the Python community to maintain? Forkable? Sure. But forkable ≠ maintainable when the dev pool is tiny. Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries? And fragmentation... Python tooling is already a mess. Pip, poetry, conda, pyenv, rye, flit, etc.—do we really need another tool in the mix? Feels like every new tool just promises to "fix packaging forever" but ends up adding another layer of complexity. Why not contribute these improvements to existing tools like pip? Sure, innovation is great, but at what point does it become too much choice and not enough cohesion? uv looks great, and I love the speed + features. But the ecosystem-level risks here... hard to ignore. Would love to see some stronger guarantees around open-source sustainability, community governance, and alignment with Python standards before jumping in fully. Otherwise, it’s just one more shiny tool that could end up abandoned or locked behind a paywall in 5 years.

dist-epoch 2y ago
> unofficial Python builds You don't need to use those, works perfectly fine with whatever Python is on the machine.
jdxcode 2y ago
> Also, what's with using unofficial Python builds by default? Even on platforms where official builds exist (macOS/Windows)? I get that these standalone builds solve certain problems (like bootstrapping), but it feels like a risky shortcut. If those unofficial builds go unsupported or change directions, where does that leave "uv"? Why not at least give users the option to rely on official binaries? The official macOS binaries wouldn't work for uv because they're not portable. They're also taking ownership over the indygreg project which is a great thing for everyone since portable pythons are useful in a lot of contexts. I'm sure they'll start sending some of the portability changes upstream too once they get there. I don't see how this is criticism.

benreesman 2y ago

Using `uv` for Python is the first time I have used Python and enjoyed the experience full stop. `ruff` is also just straight up amazing. Everything else should do us all a favor and deprecate itself tomorrow.

deleted 2y ago

[deleted]

TeMPOraL 2y ago

Someone needs to collect the data on UV's rise to popularity and do a sociological study, because from where I sit[0], UV just suddenly came out of nowhere, and despite being confusingly named[1] and backed by a for-profit company, has already captured the hearts and minds of Python developers. Between this and other tooling from that same company, it feels to me that, in the space of less than a year, Python has turned from a community language into a company-led one (like. e.g. Scala). Not saying whether it's good or bad - just that it's damn curious how this played out. It feels like Python leadership got taken over by some company almost overnight; I'd love to understand how did this happen. -- [0] - Arguably an outsider to Python community, but like everyone else, downstream of it, and always affected by it, ever since Python became the de-facto standard in Linux as the language between C and Bash. [1] - Anyone remembers libuv? Spearheading the whole async/await paradigm by powering it in Node.JS, it's one of the most known and talked about libraries ever.

dist-epoch 2y ago
Because uv is excellent in some ways and good in all ways. Pretty much all other package managers suck in some way. > confusingly named The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. > Python has turned from a community language into a company-led one That's quite a radical take, reducing a language to it's package manager and linter. > backed by a for-profit company so is VS Code
- TeMPOraL 2y ago
  > The name needs to be ultra-short, there are only so many 2 and 3 letter words which are not already taken on linux/windows. So? 3 letters isn't some magic cutoff; cutting your command down to 3 letters or less doesn't make it suddenly 10x more effective for its users. 4 or 5 letters would be fine, too. > That's quite a radical take, reducing a language to it's package manager and linter. Package manager and linter are the most fundamental tools to a programming language in a broader sense, second only to the reference compiler/implementation. The trend in the last couple decades is to, in fact, make all three part of the core, under purview of the same person or group that designs the language itself, and its standard library. I.e. if you want to "own" the future of a language, the second best option after owning the most popular runtime, is to own the most popular package manager. And I can see this happening already in discussion threads about Python I've been reading over past few months. It's not just that people are excited about UV itself, they're treating Astral as a "thought leader" now. Again, I'm not saying it's bad, or that Astral would be a bad steward. I'm just surprised to see a previously diverse/anarchic language community to suddenly feel like it'd welcome such stewardship. > so is VS Code VS Code is its own thing; sure, it sucked oxygen out of IDE space on UI front, but it also competes against JetBrains in the same space, plus, thanks to LSP, it revitalized Vim and Emacs as viable competitors and enabled creation of even more editors. In contrast, UV just put a single company in the core position to influence the direction Python as a language takes, which is a new situation for Python - one of the last few popular languages that didn't have a corporate benefactor to start and push it into popularity.

greatgib 2y ago

For me it is not great because of the new requirement for "rust" for basic Python. Does not make any sense. Especially if the main selling point is "speed". I never encounter cases where the pip install equivalent was particularly unbearably long except in very badly designed and broken projects. The kind of one that that import every possible dependency (nom style) with pinning things on broken and incompatible set of dependencies... Also, I like very much the concept of one tool for one usage. And having venv and pip is great, having one tool cluster mixing everything is not. Sure in most dummy usage cases it will be great, but you have more chance of clusterfucks and complicated unresolvable issues. Even more if developers are opinionated on a single way to do something.

the_mitsuhiko 2y ago
> For me it is not great because of the new requirement for "rust" for basic Python. Does not make any sense. The language of choice for such core functionality in the past was C. I'm not sure how much spelunking you did in the core interpreter, but the Astral rust code is much easier to understand and modify.
- greatgib 2y ago
  But C did not disappear, now you need C and Rust. If Python was based on Rust, I guess I would not mind, but it is not. Also C is also supported everywhere! And personally I don't see why Rust would be more easy to understand than C. C is really straightforward compared to Rust. All of that being said, for something as basic and important as a package manager I would except that it is implemented in pure Python so it might easily be hack, modified or fixed without requiring any compilation... Like most of pip and setup tools were. Just wait for the moment that you can't update some libraries in your code because UV will not work without being updated, but an updated version binary is not available or you need to fix/backport something, so you need to build it. But unfortunately rust devs will not care supported older systems/os, so you are fucked. And you need to upgrade your whole system just to be able to update a simple application library.

eternityforest 2y ago

Is there any way to make wheels with pinned dependencies with this? That's the main thing keeping me with Poetry. Other than that I'm super excited.

zanie 2y ago
Not yet! We're thinking about it but it's hard to do in a spec-compliant way.
- zahlman 2y ago
  What actually would be the hiccup there? Can't you just edit pyproject.toml and add the pinned transitive dependencies to [project.dependencies], and let a build backend take it from there? That's the extent of the pinning that the wheel format supports, anyway, as far as I understand.
  - eternityforest 2y ago
    Kind of hacktastic but I guess you could make an external tool that backs up pyproject.toml, sets it to have whatever is installed in the .venv as pinned dependencies, builds the wheel, then restored the old file. Seems like the kind of thing that might have some kind of edge case somewhere I'm not thinking of at the moment though.
    - zahlman 2y ago
      >Seems like the kind of thing that might have some kind of edge case somewhere I'm not thinking of at the moment though. It wouldn't support hashes, or anything else that you can't do with ordinary dependency specifiers in the project.dependencies list (spec: https://peps.python.org/pep-0508/ https://peps.python.org/pep-0508/).

Techtsunami 2y ago

I have noticed a spike in attention to UV since Anthropic announced the Model Context Protocol (MCP). After using it for MCP development, I am moving from pyenv to uv! https://www.anthropic.com/news/model-context-protocol https://www.anthropic.com/news/model-context-protocol

kkfx 2y ago

Honestly? It's excellent but it's Python only, I dream a day where NixOS/Guix Systems will be so common that anybody will use their approach to develop in any language (and the future Nix is something more digestible and Guix system will care more about the desktop, as side dreams)...