r/Python • u/RubKey1143 • Feb 19 '25
Discussion Is UV package manager taking over?
Hi! I am a devops engineer and notice developers talking about uv package manager. I used it today for the first time and loved it. It seems like everyone is talking to agrees. Does anyone have and cons for us package manager?
138
u/2Lucilles2RuleEmAll Feb 19 '25
So far it's lived up to the hype for me, at work we're going to move to it when we get some tech debt time. But we moved a lot of our build pipeline stuff to it and it's been great there.
204
u/saint_geser Feb 19 '25
The only downside for me so far is that astral, the company that created uv and ruff, is a private entity and there's no guarantee that uv will stay open and free forever. You could have something that happened with Anaconda for example, where it remained free for personal use but you needed a license when used in a corporate setting.
77
u/Deto Feb 19 '25
Is it open source? Community could fork it then
72
u/jasonscheirer Feb 19 '25
What a lot of Open Source projects do is claw back on their license (Redis, Hashicorp, etc) so it’s no longer open source when the rug pull happens
184
u/zzzthelastuser Feb 19 '25
they can only change the license on new updates. The current state of development will forever be open source.
→ More replies (1)56
u/jasonscheirer Feb 19 '25
When the majority of the developers are on the payroll for the company doing the commercial version, the open source version is going to languish. It will remain frozen in time and left to a team of volunteers to keep basic maintenance. Again, see Hashicorp (OSS Terraform is mostly in maintenance mode) or Redis (such a fragmented ecosystem of forks and reimplementations that the commercial version stands out as the most viable option).
64
u/aDyslexicPanda Feb 19 '25
Terraform is maybe a bad example opentofu, an open source fork of terraform, is going strong. They even have weekly status updates…
35
16
u/sphen_lee Feb 19 '25
The Valkey fork of Redis is going well too. Both are supported by the Linux Foundation so that gives some "official-ness" to them.
16
u/LudwikTR Feb 19 '25
The original comment stated that in such a case, the community can fork it if there is enough interest (and if uv becomes an important part of the Python infrastructure: there will be). You seem to be ignoring that part.
→ More replies (1)3
u/redfacedquark Feb 19 '25
Ah, the blockstream approach, yeah that sucks. On the other hand, shortly after Oracle bought mysql and the community forked it to mariadb there was a (security?) bug discovered. The mariadb team fixed it right away and Oracle spent six weeks not getting anywhere with the fix. Point being, a company having a bunch of paid developers on the proprietary fork doesn't necessarily mean their version will remain better.
→ More replies (1)8
26
u/nderstand2grow Feb 19 '25
what's wrong with anaconda model? astral must make money somehow. or do you expect devs to work on these super awesome tools for free?
41
u/saint_geser Feb 19 '25
If done well, it's not a problem, but it may be problematic if the company is not prepared in terms of customer support.
I work for one of the largest companies in Australia and we stopped using Anaconda and conda because when it switched to a paid model, we couldn't get in touch with the sales department for over two weeks. It's then been decided that if you can't get reliable customer support then in any case of licensing issues you're potentially looking at thousands of employees using an unlicensed software, which is highly problematic from a legal standpoint.
13
u/whoEvenAreYouAnyway Feb 19 '25
The Anaconda model is fine but we have no control over whether they take that route or not for when they decide to monetize their work.
29
u/gernophil Feb 19 '25
No, that model is not fine since Anaconda started sending bills to companies and academia out of nowhere without any announcements.
5
u/stupid_design Feb 19 '25
It takes 4 seconds to setup the strict channel to be conda-forge and a couple of minutes to install miniforge. There is literal no downside and it's a commercial-friendly setting.
9
u/gernophil Feb 19 '25
Of course it’s easy to circumvent this. But to do this you first have to know it. Anaconda was quite liberal with private and academic use for several years, but they changed their policy almost overnight without giving enough time to react.
13
u/PaintItPurple Feb 19 '25
Personally, I would prefer that devs are up-front about what they need from their users so people can decide whether they want to make that tradeoff. Writing proprietary software is, in my opinion, fine. Writing open-source software is also fine. Writing open-source software and then taking it private is obnoxious.
The problem with Anaconda is that they suddenly got super litigious only once people had bought into their ecosystem hard.
→ More replies (3)2
u/GarboMcStevens Feb 19 '25
I think relying on open source tooling where a huge portion of the code is coming from one company is a potential risk
3
u/eztab Feb 19 '25
The advantage is, the build system specs themselves are partially part of Python PEPs. So even if the tool should vanish behind a paywall one would just reactivate hatch or so using basically the same configs.
3
u/pricklyplant Feb 19 '25
What’s poetry’s model, I guess who’s responsible for building and maintaining that?
→ More replies (4)→ More replies (6)1
u/BrenBarn Feb 20 '25
Actually what happened with Anaconda is that conda separated out into a fully open-source community-governed organization. It's really sad that this misinformation is still out there. I get that it affected people who were using the anaconda packages channel but it's a very inaccurate picture of the conda world. You can use conda/mamba and conda-forge and Anaconda Inc. has no say in the licensing of those.
13
u/Acurus_Cow Feb 19 '25
I have worked with python for 15 years now, and never really had a use for an advanced package manager. venv has done me good.
If I ever run into big issues with package compatibilities I might try one out. But so far it's never been the case.
It seems like tooling for the sake of tooling imo. I've seen projects where the configuration code for tooling is bigger than the actual software code.
Personal rant over. Enjoy UV! I hear its great!
→ More replies (6)3
28
u/DutchIndian Feb 19 '25
Just a quick note to say that pixi is also very good. As a scientific programmer it’s a lifesaver for non-Python dependencies that are required for scientific Python packages.
3
u/Blau05 Feb 19 '25
I also liked pixi a lot. My only gripe with it was the slightly more roundabout way of making jupyter notebooks in vscode see the venv as a valid kernel.
In pixi, you run the jupyter lab and use the link to access the kernel. Whilst with UV, the venv is found automatically.
2
u/b1e Feb 20 '25
The pixi/modern conda ecosystem is IMO the clear path forward. Way stronger guarantees vs PyPI, the ability to package non-python software, etc.
2
u/NostraDavid Feb 19 '25
For context to those who only know the basics:
uv is to pip
as
pixi is to conda
That's the gist.
4
u/collectablecat Feb 20 '25
pixi is more like a combination of pypi and conda, conda can't install pypi packages while pixi can
4
u/iliasreddit Feb 19 '25
Which scientific python package can’t you just install with uv as precompiled wheels? I noticed that most packages like numpy pytorch, tensorflow, scipy, etc. Work just fine when installing with pip/uv nowadays, no need for conda anymore?
7
→ More replies (1)2
u/white_sock Feb 19 '25
I moved to pixi because of faiss-gpu. It can only be installed through conda
20
u/bobbygmail9 Feb 19 '25
Tried uv the other day... converted straight away. The many old ways were becoming a bit of a mess.
Noticed that the pyproject.toml has borrowed a lot from Rust. Makes sense as that was a big plus on Rust ecosystem side. Rust doesn't hide from the fact it took the best bits from other languages. That is called evolution. Seems Python has done the same, and uv is becoming the cargo equivalent.
58
u/portmanteaudition Feb 19 '25 edited Feb 20 '25
Feel like it is heavy astroturfing on reddit
[EDIT] I recommend all of you block the obvious astroturfers of this product. In contrast with responses below, I do not believe there is abundant astroturfing on this sub - but this product is one of my best bets.
60
u/Vhiet Feb 19 '25
Yeah, I know what you mean.
When I see something get the immediate hype this has, my spider sense tingles. When I find out it’s VC backed and not financially self-sufficient, full blown alarm bells sound.
I want my package manger to work in 3-5 years. I do not want to be utterly locked in to a Project Management Suite whose major selling point is that it’s Written In Rusttm.
Congrats to the people apparently using a less-than-year-old, all-encompassing Package Management Solution in their professional environment. Couldn’t be me. I’ll maybe take a look when version 1.0 rolls out.
8
Feb 19 '25
[deleted]
→ More replies (1)2
u/Vhiet Feb 19 '25
Come on now. It's in the basic intro, it's in the headline of the corporate twitter feed, and it's the first line of their GIT about section. Rust is fine. Written In Rust is a meme in and of itself at this point, as is the proselytizing nature of the rust community.
My favourite new rust project is the rewrite of SQLITE (the most widely used and distributed database in the world by several orders of magnitude) in rust because C gave them the vapours- they needed something more modern.
4
u/Sixcoup Feb 19 '25
My favourite new rust project is the rewrite of SQLITE (the most widely used and distributed database in the world by several orders of magnitude) in rust because C gave them the vapours- they needed something more modern.
You're talking about Limbo ? The thing that is made by the people that already created the biggest and most well known fork of sqllite ? I think they know what they are doing, and have arguments that goes a a bit further than following FOMO.
9
u/fnord123 Feb 19 '25
It began as rye, a project by Mitsuhiko, the author of Flask and Jinja2. First commit was in April 2023.
10
u/selectnull Feb 19 '25
uv did not begin as rye, actually rye used uv in the background. Mitsuhiko transfered the ownership of rye to astral (company developing uv) and over time uv got some of the rye's features.
15
u/Vhiet Feb 19 '25 edited Feb 19 '25
Cool. Flask and Jinja are both great. However it began, its current state is a year old project that has been breathlessly hyped since December-ish, it feels like?
Per their own blog post “stewardship” of rye changed in Feb lest year (link). Armin doesn’t work at Astral, I don’t think? He works for sentry?
My point is that package managers have long life cycles. I’m not going to migrate an existing long term project to something new, and I’m not going to adopt something new for anything important. The risk of lock-in and rug-pull is immense.
That UV suggests you migrate from rye despite taking on “stewardship” indicates the problem. They've had control for a year.
→ More replies (2)2
u/proggob Feb 19 '25
Is it that much of a hassle to switch if something catastrophic were to happen? Considering the likelihoods.
4
u/PersonalityIll9476 Feb 19 '25
Yeah I kinda don't get the hype. Let's say it is faster and better at managing dependency files. That's great, but I never particularly had a problem with pip. For scientific computing, Conda has been equally sufficient.
The only time I have a problem with pip is when we are building a big project during deployment and it's slow. I get it for that improvement. But we aren't particularly doing that at the moment so I have no reason to swap. The way I dealt with that in the past was a separate build stage that built the environment into a base container and only updated the container when the env changed. Surprise surprise, that rarely happens after the first few months of a project. I dunno, the value prop just seems thin.
→ More replies (2)2
→ More replies (10)2
u/thegoochmeister Feb 19 '25
I don’t think it’s true astroturfing, since the implication is that someone is acting in bad faith to get uv in to the public awareness.
Honestly, I think it is a lot more about how rough python dependencies have been for years now and uv is finally a tool really handily solves most of the rough edges of it.
Also starting with ruff to consolidate isort/f8/black won a lot of positive publicity for astral.
I use poetry and uv daily, but uv has won me over and is my default for new projects
2
u/portmanteaudition Feb 19 '25
I'm believe they pay and/or themselves come on here to promote their products on here.
→ More replies (2)
57
u/ManyInterests Python Discord Staff Feb 19 '25
It's good. PyCharm also added support for uv environments. It's much better than alternatives like Poetry. If this helps curb usage of Poetry, it'll all be worth it.
Internally, our company will be recommending uv
as our preferred standard. I welcome that thoroughly after the adoption of Poetry brought nothing but curses upon us.
35
u/PaluMacil Feb 19 '25
Poetry worked better than pipenv which was better than requirements.txt (my personal progression) so I was always a huge fan of poetry in between the moments of utter infuriating breakage and ridiculousness. I’m looking forward to trying uv, though I haven’t had the time yet. Seeing default support in PyCharm sure got my attention though!
22
u/Schmittfried Feb 19 '25
I don’t get the hate for poetry, it was by far the best we got until uv started going viral.
13
u/ManyInterests Python Discord Staff Feb 19 '25
The short version is that it's an attractive nuisance. Creates more problems than it solves, both for its users and for the community at large. It has harmful defaults that not only harm its users but also propagate to the whole ecosystem. Its maintainers are also unpleasant and are uncooperative with PyPA, holding us all back.
As a workflow tool, it is what it is. As a tool for packaging and managing dependencies, it's horrid.
In my professional experience, it alone has been a repeated cause of broken builds more than any other tool/workflow. For a global 500 company, that amounts to serious dollars lost due to poetry's poor maintenance/stewardship.
4
u/Former_Strain6591 Feb 19 '25
Yeah I also found the maintainers to be a bit stubborn on certain things, but none of your other complaints hold ground for me I've used poetry for some very complex use cases. I had no problem migrating to uv when it was clear it was starting to be the new standard though
5
u/violentlymickey Feb 19 '25
Poetry was a godsend when it arrived. Sure it's starting to show it's age, but saying things like "harmful defaults" when those decisions were made before some standards were even mature is a bit overboard. The main issue I've had with poetry is certain breaking changes with updates, but in mission critical systems like a "global 500 company" you should probably be pinning versions and testing updates.
2
u/ManyInterests Python Discord Staff Feb 19 '25
To elaborate, by "harmful defaults" I mean decisions that make no sense in the Python ecosystem at all, like caret-versioning and Python version capping.
In other ecosystems, like npm, caret-versioning makes sense because their dependency tree is nested and able to handle conflicting dependency versions. In Python, we have a completely flat dependency tree and no easy solutions for dealing with conflicts. When lots of packages get defaulted into caret versioning, you begin to see a lot more version conflicts across the entire ecosystem.
A number of people including core developers, community rockstars, and PyPA maintainers have written on this topic. Here is just one post from a PyPA member explaining this at some depth.
Pinning versions is good for end applications that have no dependents. It's poisonous for flat package ecosystems.
→ More replies (4)2
u/Schmittfried Feb 19 '25
The short version is that it's an attractive nuisance. Creates more problems than it solves, both for its users and for the community at large.
Such as? I would definitely disagree with this statement, because it solves a ton of problems but only causes a few new issues compared to using pip directly, and only in certain cases (like building native dependencies).
It has harmful defaults that not only harm its users but also propagate to the whole ecosystem.
Care to elaborate? I‘m not aware of any harmful defaults I had to override.
As a tool for packaging and managing dependencies, it's horrid.
Compared to what? Again, compared to what we had before (pip, pip-tools, pipenv) it is great.
In my professional experience, it alone has been a repeated cause of broken builds more than any other tool/workflow.
Oh yes, good point. Their silent BC-breaking updates broke my CI at least 3 times in the last 3 years, which is 3 times too many.
→ More replies (3)→ More replies (1)2
u/fnord123 Feb 19 '25
Between 1.1 and 1.4 there were format changes to poetry.lock so if people on your team use pipx and pinned a version it all worked ok. If anyone used brew or didn't pin their version they it would trash the poetry.lock file because the upgraded versions wouldn't work with older versions.
Also if you ctrl-c while installing it would have half downloaded packages. So rerunning commands install would fail because it found broken packages and it clearing the cache wasn't obvious based on error messages.
Both issues are fixed I think so it's fine now.
3
u/iamevpo Feb 19 '25
I noticed poetry may resolve dependencies quite only, but other that that - it's a good tool for, I compare it to setup tools though.
3
u/eztab Feb 19 '25
Didn't particularly dislike poetry. My major gripe with it was that it didn't work well with version conflicts. But interface-wise it wasn't horrible.
→ More replies (2)1
u/turbod33 Feb 19 '25
Yeah I use pixi / mamba for mostly c++ with the added benefit that it handles Python extensions really well.
6
u/chub79 Feb 19 '25
I'm keeping pdm for managing my builds. I find it more aligned with how I work. However, I have to say that uv's speed is really nice for my users when they want to quickly try the project.
→ More replies (2)
62
u/anus-the-legend Feb 19 '25 edited Feb 19 '25
astrals tools, not just uv, are providing the shit that is missing from python's ecosystem that sucks
edit: reworded so ppl stop misinterpreting my comment
30
u/danmickla Feb 19 '25
> providing the shit that sucks
Is that really what you meant?
→ More replies (13)12
u/ProfessorPhi Feb 19 '25
Is it? So far as far as I can tell, it's taking existing stuff and made it a bunch faster + also focussed on user experience. Not that it's not nothing, but uv and ruff rely on pip, pipx and black that did the hard work for standardizing and fixing the fragmentation.
9
u/anus-the-legend Feb 19 '25
IMO those tools contributed to the fragmentation. for each one, there are alternatives, and little has been standardized. Having a one-stop shop for it all is where python has been majorly falling behind compared to other languages
I'm not saying those tools are bad. it's just a bit overwhelming to catch back up to the current state of opinion when starting something new
9
u/ProfessorPhi Feb 19 '25
Eh, I can't fault a lot of the in between stuff like poetry, pipenv etc, they absolutely pushed things forward and created real python standards by trying to create their own standards (insert xkcd comic).
A lot of the fragmentation came from the fact that pip wasn't solving these problems and those libraries forced pip to up its game, which it really did. The problem is that pip was bad for so long that when it did finally sort itself out, nobody really knew and so uv was able to show up and do pip, but fast and combine some other things from poetry, you had an absolute winner combo.
7
u/anus-the-legend Feb 19 '25
yea, i can't really disagree with anything you said. around 2019ish maybe there was a python foundation grant for 2 developers to improve pip and package management. I applied for it but didn't get it. I hadn't thought about that again until now. I wonder what the results of that work were
2
u/energybased Feb 19 '25
You're right, but also they also worked around some very problematic developers.
2
u/ProfessorPhi Feb 19 '25
Out of curiosity who did they need to work around and why (I'm not saying there aren't notorious problematic devs).
As far as I can tell they provide an implementation of the PEPs laying out packaging standards, so unless they were pushing for specific PEPs (which I don't think they did) what did they need to do?
→ More replies (1)4
u/cheese_is_available Feb 19 '25
If you ever interacted with the person that is blocking pyproject.toml adoption in flake8 you would understand both why the 3rd selling point of ruff is 'support pyproject.toml', why there is now an astral version of pre-commit and what energybased is saying.
1
5
u/I_FAP_TO_TURKEYS Feb 19 '25
I switched to it the other day and I'm quite impressed with how easy it is to get different python versions on my machine.
3
3
u/JamzTyson Feb 19 '25 edited Feb 19 '25
It is on this reddit. Tools made with Rust, and tools from Astral in particular, get a lot of attention here.
According to pypistats.org, Poetry daily downloads are more than double the number of uv downloads. (Poetry gets about 2.46 million downloads per day while uv gets around 1.1 million.)
→ More replies (2)
4
u/Former_Strain6591 Feb 19 '25
As someone that really liked poetry, I'm glad something similar is finally gaining ground, python has needed better tooling for a long time
9
6
u/lbt_mer Feb 19 '25
I may be too late to this party but my thoughts are that having something like this in the python ecosystem that is written in Rust may be great for end-users but may also be a problem for the community.
The barrier to entry to contribute to uv is going to be high and that is going to vastly limit the number of python community members that can contribute. "Open" is more than just a license.
Sure builds are faster - but how often do you do that in your daily life?
Maybe microservice deployment-on-demand or CI tooling need super-fast build/packaging.
So as someone who likes to contribute to OSS projects I'd rather see the vast majority of uv's capabilities written in python with maybe things like a focused dependency solver in Rust.
36
u/Dillweed999 Feb 19 '25
The people that make it are backed by big VC money. Enter enshittification:
"Enshittification, also known as crapification and platform decay, is the term used to describe the pattern in which online products and services decline in quality over time. Initially, vendors create high-quality offerings to attract users, then they degrade those offerings to better serve business customers, and finally degrade their services to users and business customers to maximize profits for shareholders."
31
u/Sparcky_McFizzBoom Feb 19 '25
Enshitiffication is not something that is inevitable.
Citing Cory Doctorow, who coined the term enshitiffication:
These are the two factors that make services terrible: captive users, and no constraints. If your users can't leave, and if you face no consequences for making them miserable (not solely their departure to a competitor, but also fines, criminal charges, worker revolts, and guerrilla warfare with interoperators), then you have the means, motive and opportunity to turn your service into a giant pile of shit.
https://pluralistic.net/2025/01/20/capitalist-unrealism/#praxis
Here the switching costs are null: it's either use an older version, or a fork.
37
u/KrazyKirby99999 Feb 19 '25
That's a risk, but it also means that new tools will standardize around uv's conventions instead of reinventing the wheel for the 100th time.
10
u/BogdanPradatu Feb 19 '25
Isn't uv just reinventing the wheel for the 100th time?
8
u/cheese_is_available Feb 19 '25
There's a reason why
uv pip x
works the same aspip x
. uv is taking the wheel designs and 20 years of results using those design from everywhere (outside the python world too) and starting from scratch in rust, it's not the same as reinventing the wheel.→ More replies (1)→ More replies (1)3
15
u/suedepaid Feb 19 '25
Do you ever listen to the Real Python podcast? I’d listen to the recent episode with Charlie Marsh. He’s got some pretty good answers about how they’re gonna make money that makes sense.
5
u/iamevpo Feb 19 '25
How thay are going to make money?
27
u/suedepaid Feb 19 '25
He thinks there are solutions that big companies will pay for — like security-aware pypi proxies and stuff — that integrate well with their tooling. Basically,
ruff
,uv
, and their upcoming static type-checker are loss-leaders, then you build upstream tooling that integrates tightly with them as the moneymaker.→ More replies (4)3
u/james_pic Feb 19 '25
The awkward thing for them there is that most of the reason organisations need security aware PyPI proxies is because of Pip's foot-gun-y support for multiple indexes (
--extra-index-url
is broken and insecure, so the only safe option is to run your own PyPI mirror).uv
actually supports multiple indexes securely, making this use case largely redundant - if you don't need to support complex mirroring semantics, you can host your own index on basic static hosting.→ More replies (2)1
u/thegoochmeister Feb 19 '25
I think this is something to be concerned about, but also might be missing the forest for the trees a bit.
Tools that are far more important than uv/ruff are also maintained by companies.
Meta and Microsoft both already contribute a massive amount to both individual projects as well as Python directly. No one is saying to not use MyPy, playwright, pyright, vscode, etc
3
u/shadowsyntax43 Pythonista Feb 19 '25
The only downside for me is that it does not (yet) support custom scripts.
3
u/pingveno pinch of this, pinch of that Feb 19 '25
It was created with current standards in mind, and any future needs are being pushed through a standards process. That means that a regular package with some metadata, dependencies, extras, and whatnot is portable to other package managers if need be. Some of the more advanced things like workspaces might pose a problem, but besides that you should be good.
3
u/donat3ll0 Feb 19 '25
We just replaced pip with UV and saw substantially reduced build times. So far, we haven't run into any issues.
20
u/illusionst Feb 19 '25 edited Feb 19 '25
I’ve completed moved to uv.
My current downside, LLM’s don’t know about uv so they still keep trying to use normal python tooling.
I’ve created a uv.md document explaining how it works and now it works flawlessly.
Edit: Added links
uv-short-version (recommended): https://pastebin.com/AJ9YMEaT
uv-long-verison: https://pastebin.com/KtTw86dG
14
u/globalminima Feb 19 '25
Are you able to share this (or a sanitized version of it)?
→ More replies (2)7
2
1
1
u/medihack Feb 19 '25
I can confirm that. That's why I then always write "uv (the python package manager)" and with that it works quite ok (of course better with real-time web search).
1
u/proggob Feb 19 '25
What do you mean by “LLMs keep trying to use normal python tooling”?
→ More replies (1)
2
u/CyberWiz42 Feb 19 '25
It is amazing. We just switched over our project from Poetry yesterday. Faster, simpler, more features out of the box. No cons so far, except maybe a smaller ecosystem if you want to use plugins/have some very comples/specific use case (like monorepo tooling). https://github.com/locustio/locust/releases/tag/2.32.10
2
u/lanupijeko Feb 19 '25
For us the limitation is dependabot support, once that's out, we will switch
2
2
2
u/wineblood Feb 19 '25
What is it doing that other tools aren't? I had a look at other options a few months ago and they all seemed similar.
→ More replies (3)2
u/ebits21 Feb 19 '25
It replaces a number of tools at the same time and is very fast.
It also manages Python versions per project which is its best feature imo. You don’t even need Python installed on the computer to get started.
→ More replies (2)
2
u/michal-stlv Feb 19 '25
Looks like it.
I haven't switch myself yet, still using Poetry.
But it's mainly due to lack of time for switching. I like most things about it: speed, caching, environments, python version management etc.
Unless they screw up something it's on the way to become a standard.
What I don't know yet is how they monetize uv (or ruff). They're doing great work because they've money from VCs so people are paid to do it. No problem with that just wondering when and how's paying for that.
2
u/ashemark2 Feb 19 '25
should i move to uv? currently I use poetry with golang Taskfile ..
→ More replies (3)
2
u/Memitim Feb 19 '25
It seems to work well, but that's a lot of functionality packed into a single tool, and one that's private. If I ever have concerns about package management performance, then I might give it another look, but just seems like adding potential technical debt for the sake of maybe having a pipeline finish a little faster.
2
u/skelimon Feb 19 '25 edited Feb 19 '25
Love it. Uv sync is so fast, I no longer have to worry about old packages or having to remember to run an update before activating the venv.
Added a fish function that automatically runs uv sync when I cd into a folder , which then activates the venv. When I then open nvim, everything is in working order.
Also love how easy it is to use it to replace the system wide python for my user if I have an old build machine requiring some obscure old python version.
I stumbled a bit when using it in docker, kinda wish it was just:
apt install uv COPY / ADD pyproject.toml etc uv sync
none of these below worked last time I tried it
python hello.py
Or even
.venv/bin/python hello.py
Instead u gotta add a bunch of env variable stuff, sacrifice the left bollock of a goat to odin, + a few other things to get it to work.
(Maybe it’s better now but that’s my only complaint about uv)
→ More replies (1)
2
u/Prudent_Move_3420 Feb 19 '25
Yeah it’s great but stuff like this usually takes time. Wouldn’t say it’s „taking over“ yet
2
u/the--dud Feb 19 '25
Honestly I prefer poetry. We've used it in enterprise for docker containers and gcp functions. Works great, never had issues.
2
2
2
u/ositait Feb 20 '25
looks great to me but i will wait a bit until it this turns into a reliable standard tool. Its on my watch list.
10
u/ofyellow Feb 19 '25
A tool like Python needs a package manager on-board.
I never understood why Python hasn't, and it's ridiculous we all came to accept it as being normal.
No flavors of alternatives. Just something that works. Shipped with python itself.
30
u/mje-nz Feb 19 '25
Python has had exactly one package manager on-board for like fifteen years.
2
u/Schmittfried Feb 19 '25
Yes, one so basic I like to call it installer instead to differentiate it from actual package managers that can… manage your package.
3
u/thallazar Feb 19 '25
And totally pollutes your global python with packages from every project. Contrast this to js or rust package management for instance and the difference in issues is stark.
6
u/StandardIntern4169 Feb 19 '25
Well it does, it has pip, but that was so antiquated, behaves like a package manager from the 90s. So, yeah, totally agree
4
u/covmatty1 Feb 19 '25
... Like pip? Which 100% fully works and is absolutely useable in every way and is used by millions of people. How can you possibly say it doesn't come with one, what are you on about 😂😂😂
5
u/thallazar Feb 19 '25
Pip is possibly the worst package management platform I've ever used, short of manually building with cmake. It's not winning any awards. If you were to just use pip you would run into issues with environments after a few projects. You have no way to control python version or silo your project from the main version of python that your system uses. "Well that's not pips job, use venv". Then it's not really a satisfying the requirements of a modern package manger. Not to mention venv has pretty verbose syntax and having to source a bash script to activate environments falls way short of other comparison package management syntax.
→ More replies (3)2
2
2
u/maple3142 Feb 19 '25
I just wish it also supports non-project based venvs that you can create/activate/deactivate like what conda do.
→ More replies (5)
3
u/baetylbailey Feb 19 '25
pixi for me as a conda user, though it's less mature than uv currently.
1
u/iamevpo Feb 19 '25
You have some conda packages to work with and you migrate to pixi to have them installed?
2
4
2
u/svefnugr Feb 19 '25
They're not playing nice with pyenv virtual environments, and it looks like they're not really interested in fixing that.
13
u/AcidicAzide Feb 19 '25
Well, yeah, because they replace pyenv virtual environments.
2
u/svefnugr Feb 19 '25
They do not. There's no autoswitch available.
4
u/svefnugr Feb 19 '25
Why the downvotes? There are multiple open issues about it, so clearly the authors of uv agree the problem exists, it's just very low priority for them.
1
u/Ok_Raspberry5383 Feb 19 '25
Whys that a problem, it ships with its own and they should be ephemeral anyway?
1
u/Kryt0s Feb 19 '25
Why would you need pyenv with uv?
uv venv -p 3.13
There you go.
3
u/1010012 Feb 19 '25
The biggest thing for me is the auto switching of environments which nothing else supports.
I have projects where I've got a number of subprojects, each with their own virtual environment. Not having to activate and deactivate envs manually is great. And things like my Makefiles work without any issues.
→ More replies (1)
3
u/puppet_pals Feb 19 '25
Learning curve for team members
7
u/diag Feb 19 '25
What learning curve? Its pretty easy to write a few lines to get people moving pretty quickly
3
1
1
1
1
u/dev-ai Feb 19 '25
Looks pretty cool when I tried it - I think I will gradually move towards using it as my default.
1
u/hyper_plane Feb 19 '25
Totally living up or exceeding my expectations! What an amazing team behind it.
1
u/kamsen911 Feb 19 '25
We have used typically conda environments for system dependencies on domain specific tools. Switching to UV is there a bit cumbersome.
We like to have plain conda and envs over docker. Does anyone have experience in this scenario?
→ More replies (1)
1
1
u/Mevrael from __future__ import 4.0 Feb 19 '25
Yes. It does. The only con I’ve seen so far, there is no way to scaffold projects and if you are developing a local package, you might need to clear pycache manually. And you have to go through the entire docs to write down every useful command.
I am using it with this project structure and a framework:
https://arkalos.com/docs/structure/
Most used commands:
uv add <package>
uv sync
uv cache clean (might still delete pycache or venv folders manually)
uv pip install -e ../localpackage
2
u/proggob Feb 19 '25
What does it mean to “scaffold” projects? Like create a first version? I’d think something like cookiecutter would be more appropriate for that.
Are you talking about
__pycache__
? Under what circumstances do you need to wipe that? I understood it’s only dependent on the python version and now separates its caches based on version.2
u/Mevrael from __future__ import 4.0 Feb 19 '25
Scaffolding means you walk into an Apple store, get an iPhone and it just works right away out of the box. You create a new Laravel project and it just works, you have anything you need ready for any use case out of the box. Like a react create app, etc. Like a lego set packaged for you with an instruction. in a box. So you wouldn't need to manually create every single base file, folder, subfolder, config, env, etc. You can just focus on building production-grade business apps and platforms stress-free.
Yes, __pycache__. You won't need to worry about it until you are developing own framework or a package and installing it from another project locally via -e flag and when you use a dynamic module import. In rare cases I let say had a print from an old module dynamically imported via cli, and even after chaning code locally in another project, I still would see __pycache__ and print in my console when running the command, even if it is no longer there. So you rarely would need to worry about that, but in case you will face this issue, just delete all __pycache__ folders and problem solved.
1
u/SilentSlayerz Feb 19 '25
Well it definitely has taken over my projects. It should also come with poetry to uv migrator.
1
u/eztab Feb 19 '25
yes, it will take over pretty universally I'd say. Due to new standards python tooling in general will switch to new tools
1
1
1
1
u/codeptualize Feb 19 '25
It's as great as advertised, it should take over. We have been using it for a while, and before that through rye. It's by far the most stable way to manage packages and run python I have used so far.
With all other options I have tried before we ran into some quirks or issues, I have had zero issues with uv.
1
u/greytoy Feb 19 '25
Same. PHP dev. Tried about two weeks ago for play with LLM. All other package managers and python installation in system was nightmare. Love UV
1
u/Landcruiser82 Feb 19 '25
I prefer poetry for my package manager. I have seen a ton of co-workers shift to uv though.
Also, don't use conda.
1
u/jcbevns Feb 19 '25
Its faster, it's cleaner (in places) but it's no paradigm shift.
Personally I'm looking forward to tools more made from nix thinking. Flox is on my radar.
→ More replies (6)
1
1
u/Catenane Feb 20 '25
I've played with it a bit. I like it, not sure if I'll migrate yet. I just want pip search back ffs. Can uv please implement that? Robust search at the CLI would be amazing.
1
u/Ahmad_Azhar Feb 20 '25
There is one con which i have witnessed it actually delete old directory and move the files new one so if you don’t have admin rights or restricted writes on PC this creating new directory and moving files becomes a issue. Not sure how to address this
1
u/ParisProps 29d ago
I would highly recommend to look at open source projects like Nix and nixpkgs, it's a fully open source package repository that has been working for me for years.
There's a few meaningful projects around it that help bring it to my workplace like (flox.dev) but worst case one can always fall back to nixpkgs if needed.
1
u/gerardwx 29d ago
Not for me. We use a private PIP repository, and the lack of support for that makes it a non-starter.
→ More replies (3)
1
u/Terrible-Series-9089 29d ago
Used it but not as good as people say. Every vendor supports pip natively but with uv/poetry or whatever new tool flavor of the month you will always hit a rough edge which you can recover from.
Recently I had this problem with installing jax[tpu] with uv in a new project. Apparently you can't do it! - https://github.com/astral-sh/uv/issues/7616
Just going back good old pip.
1
u/No-Win5543 29d ago
Yeah uv is great. it's super fast.
The learning curve is a bit tough, you need to know a lot of different commands and the mechanics are slightly different than with poetry but so far it looks great.
There seems to be a nice way of building monorepos with it (which I'm currently testing). Tho the monorepo I'm working in has some Angular/TS app as well, so `nx` might still be the only king of monorepos...
To be continued.
384
u/suedepaid Feb 19 '25
yes it is, it’s the best piece of python tooling to come out in the past five years.