uv IS the Future of Python Packaging 🐍📦
HTML-код
- Опубликовано: 1 окт 2024
- It's been six months since I asked whether uv is the future of Python packaging: • Is UV the FUTURE of Py...
With uv 0.3.0, the answer is in and I'll tell you WHY, and WHAT’s missing to be the PRESENT of Python packaging.
🔗 Links
► Astral’s 0.3.0 announcement: astral.sh/blog...
► Documentation for the new projects feature: docs.astral.sh...
► Cross-Platform Lockfiles PEP that didn't get done in time: discuss.python...
► Production-ready Python Docker Containers with uv hynek.me/artic...
► Faster Coverage with uv in GitHub Actions: hynek.me/artic...
► Python standalone builds: github.com/ind...
► MOPUp - a Python updater: pypi.org/proje...
► deadsnakes: New and old Python versions for Ubuntu: launchpad.net/...
► Pipx: pipx.pypa.io/
► My favorite command runner Just: just.systems
► My cool shell prompt is made with Starship that works with any shell: starship.rs
► • NOX vs TOX - WHAT are ...
🤓 ME ELSEWHERE
🏡: hynek.me/
🐘: mastodon.socia...
🦋: bsky.app/profi...
🅇: / hynek
🧵: www.threads.ne...
✉️ Newsletter: buttondown.ema...
❤️ Support my work: hynek.me/say-t...
🙏 CREDITS
Music: @RPLKTR / rplktr.com/
❋ UPDATED LIST OF INACCURACIES AND CHANGES ❋
As joked in the video, many of my points are not gonna live very long, so let me keep you up to date here!
Firstly: at 13:55 I got confused by an asymmetry between `uv run --with DEPENDENCY` and `uv run --extra GROUP`. The latter changes the current venv, the former does NOT. Sorry!
On with the updates:
► As of 0.4.18 (one day after publishing! 😅), `uv run -m MODULE` works and you don't have to do `uv run python -m` as I say in the video.
It would be nice a video about workspaces with uv
I only talk about things I actually use, so y'all have to wait until I run into a monorepo. :) There's plenty of channels on RUclips who just parrot docs & blog posts. 😬
@@The_HynekYeah, and from the docs is not really clear to me how it works (i don't have much experience too), it would be useless if people just repeat what is in the doc without really using it just for content on a channel. Hope to see a video about work-spaces with uv. There is not much content about uv yet.
thanks for wearing the good shirt
Now I feel like now I'll have to match my shirts to my takes!
I will continue using pyenv and manually symlinking into my virtual environments until uv implements the entire Python interpreter as a rust macro. Which is probably closer than many are comfortable admitting. In the mean time, thanks for making this.
Thank you for the great video and blog post. Can’t wait for the next one. I found myself coming back to your channel all summer long just to make sure I hadn’t missed an update.
Thank you and I'm so sorry it's so slow. 😅
Last I checked, it did not support corporate proxies, which was a blocker for me, but I've been very happy with improvements so far!
The ability to let uv handle the needed Python version is already sooo nice!
Not a question around UV, more so about your libraries that I’d love to hear your opinion on: how much do you take into account the typing limitations when designing functionality for your libraries? I took the type hint pill about half a year ago and have been enjoying the extra level of checking that users of my library get, but not everything can be type hinted. Dataclass transforms were a huge lift, and I know you participated in the discussion for that as the maintainer of attrs. But what do you do when your feature can’t be type hinted / requires hacks? Like SQL alchemy generates type hints for tuples, which is really ugly, but fits their design. At what point do I say - interacting with my library is done in this way without type checking, and in these ways you get type checking?
With SQL Alchemy it’s different because it was designed pre-PEP 484, but what do you think developers of new libraries should be doing?
Sorry for the rambling nature of my comment, anyways would really appreciate to hear your thoughts on this!
I'm a typing enthusiast myself, and for 99% of cases I think that the design pressure that typing applies to design is a good thing (cue Lukasz's PyCon US keynote) - but there's the remaining 1% where packages like SQLAlchemy or my attrs fall, where typing is still very frustrating, if not impossible. Tin has also written about this: threeofwands.com/python-is-two-languages-now-and-thats-actually-great/
All we can do is hoping for better affordances over time and that Astral's entry into that field has a positive impact.
As a python "enthusiast" what do you think about pixi package manager.
UX feels like conda/microconda, but a bit more nicer.
I don't have an opinion because it always felt to me it's solving problems in the Conda-sphere that I have no connection to.
This is the biggest reason why I moved away from python. I can't believe this is still being decided.
Well, we'll be happy to have you back now. :)
@@The_Hynek sorry, no. I've packaged an internal project that used uv and it had loads of rough edges and resulted in a massive container. Go builds are simple (which is surprising) and result in containers a tenth of the size. Runtime memory usage follows a similar pattern.
Plus the ability to automatically generate code is more limited. Tools like sqlc and oapi-codegen (server and client generation) just aren't used in python which means loads of handcrafted bugs instead.
It's disappointing, but it's just hard to recommend python these days.
@@KevinLyda Fair enough, but I'll have to point out that you're mostly describing the trade-off between an interpreted language and a compiled language - and I can't help myself to point out that Go programs compiled on Jammy don't run on Focal.
I write plenty of Go, so I'm keenly aware of the trade-offs and have to juggle the decision for every project I start. But it's not fair to dismiss Python completely on the grounds that interpreted languages (with a varied ecosystem that require crazy pants things like Fortran compilers while in Go everybody scoffs even at cgo packages) have bigger containers or use more memory, because that simply doesn't matter at all in most contexts.
As for sqlc: it's nice, but I find codegen that pollutes my repo gross (I know, matter of taste) and SQLAlchemy in Core API mode (i.e., not the ORM nonsense) is superior to any database abstraction I had the misfortune to use across easily a dozen of ecosystems.
Anyhow, enjoy your/our Go, but nuance is great.
Nice shirt, man
💛💜
🤔that naming might be going to be confusing to google
yeah i usually search for "astral uv"
Loved the video and where uv is going, but isn't it a bit too bleeding edge for incorporating into projects to not require constant tracking and updating? As mentioned multiple times in the video, it's changing fast and many more things are yet to come/change
Well, this is obviously a trade-off question and even more so a question of trust and incentives.
So far, Astral hasn't broken anything they've officially shipped for me and given they want to be a viable alternative, I suspect they're gonna do their best to leave it that way.
It's also not like other packaging tools never break. But again, there's no definitive answer but I can say for myself that the only things I had to change in my uv usage was the removal of work-arounds.
How do you get LSPs to work with uv if you don't activate the virtualenv, because the LSP can't see which third-party libraries are installed?
I don't think that's what they mean. I mean I don't know what editor Charlie is using and you still need to pick your Python interpreter in, e.g., VS Code but I suspect that's not what he understands under "activating". Putting it into a well-known place (./.venv) has led IME to most tools auto-detecting it.
I've seen python talks from different pycons recommending Nix. Everything else new on the block is inferior, "even if it's built in Rust".
This seems like a false dichotomy right there. Devenv, for example, has uv support baked in. You don't have to use all of uv's features to benefit.
Yeah we all know npm is the only tool you need… except for nvm, and ncu, and prettier, and typescript apparently, and node itself, or maybe bun, and really pnpm and yarn and deno….. indeed, ‘modern’ JavaScript is truly the example to follow.
Do you even know what you talking about?
It's good to have options, so we can choose the best one for the use-case.
Npm, pnpm, bun and yarn are all pretty good at doing their job. Apart from yarn which is now shit since no one knows if we should use v1 or v3 (where is v2? 😂 And v3 is complete shit, but at least they forced npm to improve perf). Diversity brings resilience and quality.
Whereas pip is the worst piece of software ever written, everyday failing to install more and more packages for no reason, worst dependency resolution ever, can't give a helpful error message, and slow. And poetry is not using standard Pep 641 for pyproject.toml config + their optional dependency config is garbage. So any alternative is welcome! (Really can't wait to fully see pip go away, this is the worst software I have ever seen, no idea how it stays for so long)
Ruff has already solved python formatting and linting (byebye flake and black, happy to forget them). So we can expect the astral team will continue building well designed tools. This space is even already better than JS because eslint is a pain to configure
And uv comes packed with ruff. So you literally get npm, eslint, prettier, nvm with uv. All you need is something for static type checking.
I understand this is an emotional topic, but y’all aren’t disagreeing as much as y’all seem to think. I think it’s a good thing that uv is taking lessons from Rust and not JavaScript that is, as you admitted yourself, rather fragmented itself. Not to forget, that the whole npm platform is owned by Microsoft - which I suspect is one of the reasons why people are apprehensive of Astral being a company. We already have an npm-like package manager that I won’t name, because I hate it. “It’s good to have options.” is something we (myself very included) have been saying for years, but the normies disagreed.
If only python itself would include something good instead of relying on the community. How many package managers/ virtual environment managers do we need?
There is no such thing as “Python itself”; there’s only the CPython core team of volunteers and they’ve made clear many times that they have no interest in doing that in addition to what they already have to do. Python is not a company, they can’t just will such things into existence by shuffling employees around. Ironically, there is a venv implementation inside CPython (Python -m venv) and it’s slow as molasses.
did you just say you had a very _ruff_ summer?
but no auto-fix! :(
Hi Heynek,
Thanks for the great video 🎉
I’m curious about your books behind you. What are they?😅
Introduction to Algorithms, Code Complete, Working Effectively with Legacy Code, Architecture Patterns with Python, The Pragmatic Programmer, The Great Mental Models 1-3, and Programming Pearls!
@@The_Hynek you’re awesome 🙌
I have a bad feeling that uv, ruff, and the other tools from Astral are going to end up being a bait and switch, no matter the intentions of some of the employees. I think I prefer not to use tooling from a for profit company.
That makes no sens! Just look at the other for profit companies that do open source tooling like redhat... Oh wait
A maintainer burning out is at least just as likely as Astral rug-pulling us. In both cases we as a community have to take over. For instance, there’s essentially no original pip author still on board.
@@The_Hynek I think in many cases I might agree, but for core tooling I would rather have it in the hands of the python community. This would reduce the risk of a rug pull and simplify things going forward if the maintainer wants to retire.
In addition to a complete rug-pull where the software is completely closed up, there are other in-between situations we could find ourselves in. Some of these are worse than losing access to new versions because they would split the user base. It is better to have an abandoned project than multiple concurrent forks such as in the case of Redis or Terraform.
I mean I agree in general, the problem is that the community hasn’t produced anything comparable in over a decade of trying. The problem at hand (I talk about it more in my first video) is so much more complex than people realize, especially compared to Rust or JS. Astral is giving us a much-needed speed-bump, until the community has to take over again.
Why do you talk about version 0.3.0? That came out more than a month ago. The current version is 0.4.17. But anyway, I agree that uv is awesome. I'll switch to it from poetry. Poetry is also good, but uv is faster.
I don’t talk about 0.3.0 (much) - I talk about what it changed and what happened ever since. The contrast between 0.3.0 and now (which I DO talk about) is the very reason why I’m bullish.
@@The_Hynek OK. But you link v0.3.0 is the video description.
@@jabuci yes, that's when the big project management features came out. The link is a blog post announcement.
Thank you so much Hynek for summarizing uv's status and all the ripple effects it has in this video; worth the wait, as with all of your videos!
Many thanks also for your very pragmatic and optimistic responses in the Python Mastodon threads. You (and Charlie) are bringing a very fresh and positive view in the ecosystem, that really gives me hope we're finally up for some worry-free years for the Python packaging saga🤞
Wow thanks, that's quite the praise! 💛