While working on a PhD in technology and education, I thought that it might be worth creating a SaaS for people to teach whatever they want. This was back in early 2008, when such sites didn't exist. I assembled a team, and we made some progress, and even got a commitment from one funder. But I didn't really understand how to manage the team, and everyone was working very part-time on the project, and we didn't really have anything serious we could show, even after a few months. And the funder was only willing to invest if we found a second investor, which we didn't. So we ended up abandoning the project.

I think that we had some great ideas, including guiding instructors in the creation of online classes using the best proven pedagogical tools and theories. You could connect lessons to standards (if you were in a school, or wanted to be associated with one), or could do it free-form, or could use templates of various sorts.

I ended up finishing the PhD, so I can't complain too much! And as I wrote, I was probalby not a good person to run a startup; I'm much happier with my life as a bootstrapped freelancer. But it was hard to realize that I spent a year or so working on this with very little to show for it -- especially knowing that it might have thrived under a more experienced leader.

A lot of people I know, including many of my students, first heard about uv as a lightning-fast replacement for pip. That's what piqued their interest, and that's also more or less where they stopped. Just yesterday, someone was asking me about whether uv knows about handling different versions of Python, or if it only installs packages.

So your points are all valid -- but I'm trying to address pain points people have repeatedly raised, and that I myself experienced, and flatten the learning curve for as many people as possible.

I dunno, every single conference I've attended over the years had at least one talk trying to make sense of packaging -- downloading, installing, venvs, creating wheelfiles, and distributing to PyPI. It was nice to say that you could choose your own tools, but it was a huge, confusing, daunting mess for many people.

I had some thoughts about how things could improve, but the core developers said that anyone with their own ideas had better think through all of the implications, because packaging is super hairy.

The uv folks basically took that as a challenge, and said, "What if we have one package manager that replaces literally everything else in the packaging ecosystem, hiding the stuff that people find confusing or annoying?" Color me impressed; they really did it.

Sorry to disappoint! I can tell you that many people I've met, including those who have read the documentation, kept asking questions about how to use uv. This article is a summary that I came up with, based on my experience and theirs.

System-wide package installs are a weird quirk of my own work, since I'm doing very little product development and lots of one-off classes. I'm not at all recommending that "normal" developers do this, and I make sure to say that in all of the courses I teach.

I teach Python professionally, and constantly get questions from my students about how they should be using uv, and how to integrate it with pip, pyenv, venvs, and the like.

When I shared this post with them, my students said that it clarified things they didn't previously understand, even after reading the documentation. Part of the problem is that the documentation describes lots of options, rather than explicitly encouraging one particular path and model.

So I don't think it's just me; people are excited about uv, but aren't quite sure how to use it. But hey, I could be wrong!

As for your comment about venvs -- I teach them, I demonstrate them, and I use them when I work on programming projects.

I mostly create one-off Jupyter notebooks, which don't (in my opinion) merit their own venvs, because I don't care about locking versions. That said, I'm switching everything such that every class I teach will have not only a GitHub repo, but also a uv project, and thus an implicit venv behind the scenes. I still don't have to worry about package conflicts, but I want to be more in line with community conventions.