A year of uv: pros, cons, and should you migrate
A year of uv: pros, cons, and should you migrate
no cons. you should migrate. I didn't read the article.
That's pretty much the conclusion: you should try uv first, and there's a small chance it doesn't work for you and you're not willing to fix it, or it's out of your hands.
Examples include legacy projects and companies that don't allow it (but I do question how they'd even enforce this, and how developers can even do their jobs if they can't run binaries at the user level).
Well I can think of a couple:
- It makes heavy use of caching and occasionally that goes wrong and give confusing errors until you think to
uv clean - It's an extra step to install
uvwhich you may not want to impose on users, or CI. - Astral might die.
But it's sooooo much better than the official tooling (and the competition like Poetry) that the conclusion is still the same: you should definitely use it.
- It makes heavy use of caching and occasionally that goes wrong and give confusing errors until you think to
What do you do when there is/are unavoidable package dependency conflict(s)? <-- biggest question in Python
Often times, split out into mutliple venvs.
For example,
Sphinxrequires py310+. My default is py39.myst-parserrestricts dependencies rather than allow the latest and greatest. So there is an unavoidable need for two venv.After setting up pyenv, how much setup is required, in
pyproject.toml, to setup these two venv?Looking at poetry, it's focused on one venv. And it's annoying it considers
pyproject.tomlto be a r/w file. I want to configure for an unlimited number of venv.Python is used in so many different contexts it's extremely hard to create "one tutorial to rule them all".
On that subject but also kinda out of topic, does anyone have good resources for learning Python?
My gf is very into excel macros and could benefit from Python as a data analysis tool, but as all resources online are paylocked it's hard to get an idea of their quality. She's also the learn-by-examples kind.
I learned python from codecademy back in the day, are they still around? I remember their examples/course being very interactive and completely free
Yeah, they ask for your payment details after the second section of their Python course 😢 I think I read somewhere that their Python 2 course was still free, but it's not very convenient. Paying would be okay, but it's hard to get an idea of what you get for the price without asking around 🤷♂️
Real Python is great in general! They explain stuff well and correctly. I don't know if it's good for learning start to finish, but at least if there's a specific topic you need to deep diver deeper into. It's my go tho when exploring a new python related topic.
The OP author is very familiar with uv, having written multiple articles on it. Pushes it onto his students. So i get it, the article is focused on uv and he is invested in uv. This assessment is a tiny bit unfair, but enough, only, to justify reading the article with a tiny grain of salt.
For package management, i'm happy with pyenv. So there i have a bias.
The biggest praise i have is, it follows the UNIX philosophy,
do one thing and do it well. uv does multiple things, the issue comes down to resources required to maintain a super complex thing. Especially in a completely different coding language! I DONT GIVE TWO SHIATS IF ITS FASTER, I care about maintainability after the original geniuses disappear and they will.dependency management
Any blog post which doesn't mention competitors, tiny grain of salt --> giant grain of salt.
If not mentioned, have to assume either don't know about them or haven't bothered to try them.
What are the actual competitors to uv (specifically for dependency management)?
The only package mentioned is: poetry
poetry also violates the UNIX philosophy. It combines build backend with dependency management. I want them separate.
Open up that super powerful doom pr0n machine, AI, and get it to find the other (dependency management packages). Mention them in the blog post.
The article quite clearly mentions competition:
Because I'm a freelancer dev, and also a trainer, I get to navigate those waters and I've seen all other tools fail spectacularly. pyenv, poetry, pipenv, pdm, pyflow, pipx, anaconda...
As well as discusses anaconda later in relation to CLI and GUI.
The speed is really fantastic, there's nothing else I can say. If you don't see a benefit, the it's fine of course. But going from insanely long resolution times in my previous work place using conda to now resolving stuff in a matter of seconds is incredible. uv is the first tool I have used for Python that just feels right.
I recommend listening to the podcast from Real Python that talks with Charlie, they discuss the commercial aspect https://realpython.com/podcasts/rpp/238/
The biggest praise i have is, it follows the UNIX philosophy, do one thing and do it well.
That isn't a pro on its own, and it's also a very wooly rule. Uv does one thing and it does it well - Python project management.
the issue comes down to resources required to maintain a super complex thing
They seem to be managing fine. I guess having a company back it is enough. But that is also probably my biggest worry about it - what if Astral goes away (which given their apparent lack of business model I suspect they eventually will)? Hopefully uv is popular enough by that point it won't die.
I DONT GIVE TWO SHIATS IF ITS FASTER
It's literally 10x faster. I'm not sure what kind of person wouldn't care about that.
It’s literally 10x faster. I’m not sure what kind of person wouldn’t care about that. On that, lets agree to disagree.
Thru magic Astral has funding. I don't. So why shoulder the risk that their magical situation will continue forever.
When Astral goes tits up, which we seem to agree on, and everyone is whining crying and screaming, at least there is one or more fallback(s) written in Python which is/are maintainable by people without magical super powers.
"Do one thing and one thing well"
This is why the Python landscape is such a mess in the first place. The "one thing" should have been project management. Instead, we end up with 20 different tools that have a very limited context, often overlapping or being mutually exclusive to each other in functionality, and it's up to each project to adopt and configure them correctly.
The mass adoption of uv is a clear sign that we're tired of this flawed approach. Leave the Unix philosophy to core utilities of an OS.