Data on the number of releases comes from ecosyste.ms which was very convenient to do this while comparing with other packages outside PyPI. For what it’s worth, Rails is at 510 on there, which I believe is all releases since 2004. And Laravel is at 247 but there’s 2-3 years missing
it’s my 1st attempt at reporting on CI downloads specifically. Interpreting this is more of an art than a science, I’d love to hear if others have ideas on what to do with this data!
for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more
The pace of uv adoption is insanely fast. It's directly related to how bad the previous Python tools were/are. Even to seasoned veterans set in their ways - they still know a better solution when they see it.
uv having a good pip compatibility layer probably helped a lot, because you could try things out that way and see what fit, so to speak.
It's probably worth mentioning that Astral (The team behind uv/etc) has a team filled with people with a history of making very good CLI tooling. They probably have a very good sense for what matters in this stuff, and are thus avoiding a lot of pain.
Motivation is not enough, there's also a skill factor. And being multiple people working on it "full time"-ish means you can get so much done, especially before the backwards compat issues really start falling into place
uv was really smart in the way they integrated with existing solutions. My whole team just switched over from pip, and it was painless. We were already using pyproject.toml files which made it even easier, but uv also has documentation for transitioning from requirements.txt files.
I feel like I've tried at least 5 different package management tools for python. Between pip, poetry, pip-tools, pipx, I'm not really sure what easy_install, egg, pkg_info are, but I do know I have always been surprised I need to care.
It sounds like uv is a drop-in replacement for pip, pipx, and poetry with all of their benefits and none of the downsides, so I don't see why I wouldn't migrate to it overnight.
Honestly, I was skeptical when I learned about uv. I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years.
Then I gave it a try and it just worked! It’s so much better that I immediately moved all my Python projects to it.
> I thought, just Python needs, another dependency manager… this was after fighting with pip, venv, venvwrapper, and poetry for years.
Pip, venv and virtualenvwrapper (people still use this?) are not meaningfully "dependency managers". A venv is just a place to put things, and pip does only basic tracking and tries to maintain a consistent environment. It isn't trying to help you figure out what dependencies you need, create new environments from scratch, update pyproject.toml....
Pip's core capability is the actual installation of packages, and uv does a far better job of that part, using smarter caching, hard links to share files, parallelized pre-compilation of .pyc files, etc. Basically it's designed from the ground up with the intention to make lots of environments and expect starting a new one to be cheap. Poetry, as far as I was able to determine, does it basically the same way as pip.
I actually did use virtualenvwrapper quite a bit until uv. I had built up various shell aliases and functions, so it was fairly painless to create and manage venvs. uv just means that I don’t have to think about that part now.
You don't even need to edit any files yourself for most simple use cases.
uv init
uv add package
uv run program.py
That's it.
If you inherit a codebase made this way from someone else, merely running uv run program.py will automatically create, launch the venv, configure packages, run your script, seamlessly on first launch.
Uv lets you almost forget virtual environments exist. Almost.
Yep. Poetry was such a delightful upgrade from pipenv, which we’d tested as an upgrade from bare pip, which didn’t have a dependency resolver at the time. If someone’s already fully bought in on poetry, that’d be the one case where I could plausibly imagine them wanting to leave well enough alone.
For everyone else, just try uv and don’t look back.
Between this and the relative color syntax, looks like much cleverer theming options are on the way, yay for more control for end users. For anyone discovering APCA, aside from it giving better results, I’ve also found it super interesting to read about the logic behind the algorithm. The Easy Intro mentioned in the article (https://git.apcacontrast.com/documentation/APCAeasyIntro) is well worth the time and it has all the relevant follow-up resources.
ty! We have no plans to rewrite Wagtail in Rust but I hope there’s ways in which we can make the developer experience better, particularly around dependencies management
A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.
n=1 but i've tried "manual" .venv, conda/miniconda, pipenv, poetry, and finally now at uv. uv is great. poetry feels like it's focused on people who are publishing packages. uv is great to use for personal dev, spinning up/down lots of venv, speedy, and uvx/uv script is very convenient compared to having all my sandbox project in one poetry env.
With the caveat I only have the package installers usage data for Wagtail downloads – pdm usage has fallen off a cliff, from 0.2% of downloads in January 2024, to 0.01% in January 2025. Roughly matches the uptake of uv.
Doesn’t make pdm bad in itself but that means there’ll be fewer pdm users around to report bugs, potentially fewer contributors to it too, fewer resources, etc.
Indeed, on one hand PDM works great, but on the other hand we wouldn't want to choose a package manager which might not be maintained anymore after a few years because there are just not many users of it.
Well, seems like 100% what’s going to happen (for the majority of Wagtail users at least) if the current trend continues. I’m not sure if that’s a good thing to be frank. But we’ll have to adjust regardless.
As a semi casual user of python that had to battle w/ dependency management recently, can you elaborate on why that would not be a good thing ?
I thought about switching our project to uv but could not find the time necessary
Sure – and I think it’s certainly proving to be a good thing so far! My concerns are more longer-term. I see two primarily:
(1) As uv’s governance is driven by a for-profit company, I see incentives that will eventually compromise on its benefits.
(2) Python packaging has historically been very fragmented, and more recently there’s been lots of work on standardization. That work will be impacted when users massively shift to one package installer.
Neither of those things are clear negatives, but they’re worth being aware of.
> That work will be impacted when users massively shift to one package installer.
Charlie Marsh (who founded Astral that develops uv) is very engaged in the standardisation process around Python packaging. The whole idea around uv is to be something that follows the standards as much as possible. uv has been much more aggressive about conforming than the other package managers.
yep, I really appreciate their current efforts, but still think it’s a point of concern. Feels risky to have so much of an ecosystem resting on so few people (bus factor, governance, etc). Hopefully with Astral being a for-profit business they’ll find ways for their work to be more sustainable than other package managers’ maintainers.
Took me all of about 10 seconds after I decided to switch from Poetry and PipX. Been just learning it bit by bit as I go along and been really pleased with it thus far.
See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.
Thanks for chiming in! Do you think it’s desirable for it to stay "ugly" then if it’s for "internal use"?
I can understand the admin isn’t meant to have a "consumer" UI but it still feels like there are lots of user experience & accessibility improvements needed to bring it in line with modern standards (WCAG for example).
