Remix.run Logo
Hamuko 8 hours ago

Do you have any statistics for that?

jengland 8 hours ago | parent | next [-]

uv has almost 2x the number of monthly downloads Poetry has.

- https://pypistats.org/packages/poetry - https://pypistats.org/packages/uv

In the 2024 Python developer survey, 18% of the ecosystem used Poetry. When I opened this manifold question[0], I'm pretty sure uv was about half of Poetry downloads.

Estimating from these numbers, probably about 30% of the ecosystem is using `uv` now. We'll get better numbers when the 2025 Python developer survey is published.

Also see this: https://biggo.com/news/202510140723_uv-overtakes-pip-in-ci-u...

[0]: https://manifold.markets/JeremiahEngland/will-uv-surpass-poe...

pm90 8 hours ago | parent | prev [-]

anecdotally every place ive worked at has switched over and never looked back.

_moof 7 hours ago | parent | next [-]

Same. It's game-changing - leaps and bounds above every previous attempt to make Python's packaging, dependency management, and dev workflow easy. I don't know anyone who has tried uv and not immediately thrown every other tool out the window.

macNchz 6 hours ago | parent [-]

I use uv here and there but have a bunch of projects using regular pip with pip-tools to do a requirements.in -> requirements.txt as a lockfile workflow that I've never seen enough value in converting over. uv is clearly much faster but that's a pretty minor consideration unless I were for some reason changing project dependencies all day long.

Perhaps it never grabbed me as much because I've been running basically everything in Docker for years now, which takes care of Python versioning issues and caches the dependency install steps, so they only take a long time if they've changed. I also like containers for all of the other project setup and environment scaffolding stuff they roll up, e.g. having a consistently working GDAL environment available instantly for a project I haven't worked on in a long time.

imp0cat 3 hours ago | parent [-]

2 things: First, you can (and should) replace your `pip install` with `uv pip install` for instant speed boost. This matters even for Docker builds.

Second, you can use uv to build and install to a separate venv in a Docker container and then, thanks to the wonders of multistage Docker builds, copy that venv to a new container and have a fully working minimal image in no time, with almost no effort.

shawnwall 8 hours ago | parent | prev [-]

been in the python game a long time and i've seen so many tools in this space come and go over the years. i still rely on good ol pip and have had no issues. that said, we utilize mypy and ruff, and have moved to pyproject etc to remotely keep up with the times.

jitl 7 hours ago | parent | next [-]

uv solved it, it will be the only tool people use in 2 more years. if you’re a python shop / expert then you can do pip etc but uv turned incidental python + deps from a huge PITA for the rest of us, to It Just Works simplicity on the same level or better than Golang.

pdntspa 7 hours ago | parent | next [-]

Then can they please figure out some way of invoking it that doesnt require prefixing everything with 'uv'

arw0n 4 hours ago | parent | next [-]

For any command, you can create an 'alias' in your shell config. That way you can get rid of the prefix.

maleldil 6 hours ago | parent | prev | next [-]

You can source the virtualenv like normal.

cjp 6 hours ago | parent | prev | next [-]

direnv, .envrc, "layout uv"

https://github.com/direnv/direnv/wiki/Python#uv

tomrod 6 hours ago | parent | prev | next [-]

alias in ~/.zshrc?

malcolmgreaves 6 hours ago | parent | prev [-]

uv run bash/zsh/your shell of choice

1718627440 7 hours ago | parent | prev [-]

I don't want software on my computer, that just downloads and installs random stuff. This is the job of the OS in particular the package manager.

jitl 3 hours ago | parent | next [-]

You're welcome to live in the 90s dark ages, I feel this attitude and the shape of the old linux distros like Debian that laboriously re-package years-old software have been one of the biggest failures of open source and squandered untold hours of human effort. It's a model that works okay for generic infrastructure but requires far too much labor and moves far too slowly with quite a poor experience for end users and developers. Why else would all modern software development (going back to perl's cpan package manager in 1995) route around it?

zbentley 7 hours ago | parent | prev | next [-]

Do you not use non-OS package managers?

If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?

1718627440 6 hours ago | parent | next [-]

> Do you not use non-OS package managers?

Mostly no, sometimes I give up and still use pip as a separate user.

> If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool

I haven't felt the need to use Go, the only Java software I use is in the OS repo. I don't want to use JS software for other reasons. This is one of the reasons why I don't like Rust rewrites. Python dependencies are very often in the OS repo. If there is anything else, I compile it from source and I curse when software doesn't use or adheres to the standard of the GNU build system.

maleldil 6 hours ago | parent [-]

I hope you understand you are part of a very, very small minority.

LtWorf 4 hours ago | parent | prev [-]

Personally I run "apt install whateverineed"

dotancohen 3 hours ago | parent | prev | next [-]

In general I agree with you. But not for software dev packages.

The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.

wiseowise 3 hours ago | parent | prev | next [-]

Don't worry, gramps, pip won't trigger your tinfoil hat.

QuantumNomad_ 7 hours ago | parent | prev | next [-]

What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older.

And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

1718627440 6 hours ago | parent [-]

> What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older.

I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all.

> And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.

mirekrusin 7 hours ago | parent | prev | next [-]

Then don't use it?

maccard 7 hours ago | parent | prev | next [-]

Do you use pip?

nimchimpsky 7 minutes ago | parent | prev [-]

[dead]

tomrod 6 hours ago | parent | prev [-]

Geospatial tends to be the Achilles heel for python projects for me. Fiona is a wiley beast of a package, and GDAL too. Conda helped some but was always so slow. Pip almost uniformly fails in this area for me.

crimsoneer 6 hours ago | parent [-]

Yup, the fact UV just installed geopandas out of the box with no issues blew my mind.