You are assuming that everyone makes the same mistakes you do and write an article about it that basically just rehashes the documentation?
>> But actually, that’s not quite true — I don’t really use virtual environments very much, so I would just install packages on my global Python installation
This is an absolute red flag especially for someone who teaches python.
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.
That's quite a bold statement to assume that the reader is probably using uv wrong.
I'll give some unsolicited advice while on topic:
On Linux, on your development machine, don't use your system python for your venvs.
Your system's python belongs to your system, not to you.
It's a critical system dependency and you don't want to depend on it not changing its version after a system update.
Uv makes it easy to download its own python, there is the env var UV_PYTHON_PREFERENCE=only-managed to make the system python disappear from uv completely.
These titles 'you are ... doing it wrong' always suprise me, partly because the problem is not really there.
These type of titles convey some kind of 'i don't understand it/ did it wrong, therefor everybody must be doing something wrong, because I cannot be the one making the mistake here.'
This is right up there with:
- 10 things you didn't know about XYZ
- etc
I prefer using a general tool manager like mise to manage runtime versions. It works consistently per language and doesn't change how you launch programs.
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.
This was a disappointing article: based on the provocative title, I was hoping to learn something new. Everything in here is already clear to anyone who has read the "Getting Started" page of uv, and I don't know anyone who is making these mistakes (system-wide package installs on a venv-first package manager?) with uv.
I'm going to be honest: uv made sense to me because I already knew poetry and it was mostly a glance at the intro and then searching to figure out how to do XYZ that I already knew how to do. I can't really say learning about uv workspaces make any freaking sense to me from to docs. I don't think it's unfair to consider uv's documentation to be reference material rather than learning tools.
Now, I'm not saying I learned anything from the article (I gave up when it was talking about "uv pip" which I have never ever used and have no real idea why anyone would ever use, but that's okay). I don't think the article is a good fit for the HN python audience, and that's also okay. But I don't doubt many people can find value in it. "uv pip" exists even though I have never used it so clearly someone must be using it. I haven't used pip in years so it's not a reference point I am starting from. People do use pip and that's okay. Those people didn't suffer through figuring out poetry etc.
I do suspect that people who do system install of packages want uv workspaces. I think I want to migrate to that for my less engineered one-off jupyter calculations stuff since so far the things I've managed to get working for that sort of project have been either monorepos (which have their own issues) or millions of venvs (which constantly sync and take up space). But again I've tried to read and figure out that uv workspaces workflow and I give up after an hour or so of not figuring it out. So that's just to say I have learned to only go to astral's docs as references and even then they are incomplete (I had to guess a bit how to add a git repo via ssh as a dependency)
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.
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.
You are assuming that everyone makes the same mistakes you do and write an article about it that basically just rehashes the documentation?
>> But actually, that’s not quite true — I don’t really use virtual environments very much, so I would just install packages on my global Python installation
This is an absolute red flag especially for someone who teaches python.
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.
That's quite a bold statement to assume that the reader is probably using uv wrong.
I'll give some unsolicited advice while on topic:
On Linux, on your development machine, don't use your system python for your venvs.
Your system's python belongs to your system, not to you. It's a critical system dependency and you don't want to depend on it not changing its version after a system update.
Uv makes it easy to download its own python, there is the env var UV_PYTHON_PREFERENCE=only-managed to make the system python disappear from uv completely.
Thank me later.
These titles 'you are ... doing it wrong' always suprise me, partly because the problem is not really there.
These type of titles convey some kind of 'i don't understand it/ did it wrong, therefor everybody must be doing something wrong, because I cannot be the one making the mistake here.'
This is right up there with: - 10 things you didn't know about XYZ - etc
Choose a better title
I think uv is probably taking on too much.
I prefer using a general tool manager like mise to manage runtime versions. It works consistently per language and doesn't change how you launch programs.
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.
This was a disappointing article: based on the provocative title, I was hoping to learn something new. Everything in here is already clear to anyone who has read the "Getting Started" page of uv, and I don't know anyone who is making these mistakes (system-wide package installs on a venv-first package manager?) with uv.
I'm going to be honest: uv made sense to me because I already knew poetry and it was mostly a glance at the intro and then searching to figure out how to do XYZ that I already knew how to do. I can't really say learning about uv workspaces make any freaking sense to me from to docs. I don't think it's unfair to consider uv's documentation to be reference material rather than learning tools.
Now, I'm not saying I learned anything from the article (I gave up when it was talking about "uv pip" which I have never ever used and have no real idea why anyone would ever use, but that's okay). I don't think the article is a good fit for the HN python audience, and that's also okay. But I don't doubt many people can find value in it. "uv pip" exists even though I have never used it so clearly someone must be using it. I haven't used pip in years so it's not a reference point I am starting from. People do use pip and that's okay. Those people didn't suffer through figuring out poetry etc.
I do suspect that people who do system install of packages want uv workspaces. I think I want to migrate to that for my less engineered one-off jupyter calculations stuff since so far the things I've managed to get working for that sort of project have been either monorepos (which have their own issues) or millions of venvs (which constantly sync and take up space). But again I've tried to read and figure out that uv workspaces workflow and I give up after an hour or so of not figuring it out. So that's just to say I have learned to only go to astral's docs as references and even then they are incomplete (I had to guess a bit how to add a git repo via ssh as a dependency)
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.
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.