❋ LIST OF CORRECTIONS AND UPDATES - last update 2024-10-26 ❋ 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: ► 10:11 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. ► 14:32 As of 0.4.27 (2024-10-25), uv has multiple development groups!
1:54 I gotta say, as a Java developer who only dabbles in python every once in a while, the whole deal with packaging, virtual environments, wheels and so on, has deeply confused me to no end, but after checking out your previous video all the unanswered questions I had in the back of my head have been resolved. Honestly surprised such a well-informed person with entertaining videos like yours has fallen under my radar till now! Instant new sub, hope you keep making videos explaining all these historical aspects about the Python ecosystem in such a concise manner
I'm very glad to hear it did its purpose! The first video should probably have been two, but I suspect the uv angle lured more people in than if it were just about the packaging part. :)
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.
Fantastic video! I really think you nailed both the technical and human aspects of this sea change in Python packaging. I especially appreciate how you called out all those giant shoulders the Astral folks are standing on. Ruff and uv are amazing tools and they are great partners in helping guide standards to keep interop, multi-culture, and innovation alive.
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!
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 UA-cam 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.
Great video as always! really happy about uv progress recent time, hope we will finally have at least somewhat standard for basic package management needs 😅 Also I really would like to see a video or a blogpost why to write python applications as a packages!
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.
The only real issue I've had with uv is that "uv tool"/uvx has a slightly awkward interface compared to pipx. Otherwise, it's been a fantastic improvement over everything that's come before, and I'll be very happy when rye's functionality is fully integrated into it.
I have been a python fan since the python 1.5 days (and my previous language experience was pre-standard javascript and pre-standard C++, so I always found it quite impressive), but as great as I have always found it, it has often been hard to be a python fan. The build tooling and package management in a lot of other languages is so much better.
"It automatically installs..." Uh? How? Where? How do I remove crap that some random uv thing automatically installed? How can I see what has been automatically installed? How does the automatically installed things integrate with proper system packages (say, on a debian-based distro)?
Where: `uv python dir` How to prevent: `UV_PYTHON_DOWNLOADS=never ` How does it integrate: it doesn't, that's the whole point. People have been begging for a decoupling forever. If you don't want that, the the env variable or pass `--no-python-downloads`. I set the variable in all my Docker base images.
Pip is not replacaeable by uv pip. Order matters with uv pip. Pip probably does but I never managed to recreate it. With uv pip order matters albeit with a clear way how.
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.
Wdym by manually symlinking?? I use pyenv + pyenv-virtualenv. The process of starting a new project is as simple as: 1. Create the venv: `pyenv-virtualenv 3.12.1 my-new-project`, 2. Ensure youre in the directory of your new project and then set it as the venv for the project's directory: `cd /some/path/myproject && pyenv local my-new-project`, and then you're ready to go. There's no manual symlinking required, hence why I'm confused by your comment..
Nuitka is a Python to C++ compiler, that's something different entirely. uv is only about packaging Python code and an alternative to Pip (since last video) and/or PDM/Poetry/Rye (since this video).
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.
Hi Hynek, good video. Can you make a detailed video of what it does that env+pip+weel+bash doesn't? Because other than the performance improvement, I don't see any other improvement over the default tools. Even the lacking stuff on uv can be done with what we already have. For example, to install development dependencies you just create a dev_requirement.txt and run pip install -r dev_requirements. What am I missing?
Until 0.3.0, it was all speed (see my older video - there's a lot more context). Now, most of what uv adds is comfort and misuse safety. As I say in the video: you can give a project to a total newb and they can run `uv run pytest` and uv takes care of EVERYTHING. They can git pull some updates that update dependencies and `uv run` again, and uv will make sure all updates are applied. This eliminates a lot of problems that plagued teams before. Finally, to borrow my own words: the cross platform lock file is the crown jewel of post-0.3.0 uv. It's a HUGE deal if you need to develop across architectures like I do (ARM vs Intel) or across operating systems (macOS vs Linux vs Windows). This works for .txt lock files only when the dependencies are exactly the same, which they often aren't. For this you used to have to use PDM and Poetry that come with their own sets of problems.
@@The_Hynek that's nice. I didn't realize that it joins a lot of tools together into a single one, included automatic git pulls and so on. It greatly simplifies the workflow.
Love this video i subbed and enjoy your technical videos! i would love a workflow video about how you build an application with UV and how you use UVX with it. Or this could be a blog post whatever you prefer! keep it up!!
Thank you! 💛 `uv tools` and `uvx` are tools that you don't use with your own project (that would be `uv run`). They are the replacement for `pipx`: so if you have Python tools that you want to use outside of projects, it manages virtualenvs (and Python versions) for you. For example `uvx --from httpie http httpbin.org/json` or `uv tool install --with tox-uv tox` (and then you can run `tox` in your shell whereever you are).
@@The_Hynek would love migration video .. i think this fit with most people as a challenging usage while uv init to start a new project is the easiest to do
The problem with migration videos is "migrate from WHAT?" - one of the problems uv is solving is that currently there's virtually an infinite amount of workflows.
So happy not to use attrs, you can't imagine! Just kidding =) The video has a great pitch, always like the videos despite me not having any idea of how packaging works. I simply use it and it rarely shoots me in the foot. Liked the experience of rye, if uv creates even better tool - I would happily use it in new projects
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.
I'm trying my best to follow the rough rule that I don't speak ill of other people's projects which has the unfortunate but inevitable consequence that I'll never speak about Poetry.
sadly I can't, because I've bounced of NixOS many times. However, I've already heard from Nix friends that they plan on creating something like poetry2nix for uv's - and hopefully eventually Python's official - lock file format.
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.
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!
We have to see things in relation to the reality that we live in. Yes, there’s the heat end of universe. And yes, Go programs compiled on Jammy don’t work on Focal. But relative to the CURRENT jankiness of existing tools, it‘s IMHO fair to use the mild hyperbole of "never".
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.
There is a bit of history to this angst in the Python community: large parts used to be written in C and we worked for many years to port them to Python, if possible. Making it more approachable and maintainable. That’s how the Mastodon thread starts, in fact. Starting to add Rust is a step back in that sense, but IMO that isn’t really comparable. But it certainly does feel so for some.
Imho writing tooling for language A in language B is a very bad smell. I get that Rust is a shiny object but now whoever is using the tool is unlikely to understand how to debug and fix the tool. Conversely those writing the tool don't need to understand the target language.
I cannot open-source our work repositories, but I promise I'll make a video once it's possible to use uv's project workflows for open-source projects (that aren't applications for Docker deployments etc).
I cannot speak for Astral, but they’re maintaining both right now and made it clear that uv wi take over eventually: github.com/astral-sh/rye/discussions/1342 but not until its “better”: github.com/astral-sh/rye/discussions/1164 Since I don’t use Rye myself, I cannot weigh in on it usefully.
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.
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.
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.
@@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.
@@The_HynekI like to say that go and python are both awesome for opposite reasons. 😎 This is my first time seeing my channel, but means your a good natured responses got my attention as much as the video. I too have fatigue over Pyphon packaging and dependency management. Pipenv and poetry both gave me some hope, but both let me down. I'll try uv soon, and I expect it will be nice. Unfortunately, I think some of the pain points will never go away because backwards compatibility complicates dependency graph resolution and additionally interpreted languages will always have more unexpected breakages during upgrades. However, I have optimism that Python will remain my second favorite language after Go for a very long time.
@@KevinLydaI think it really depends on what you use it for. I use it for math/physics/viz, for me there is no alternative. MATLAB is literally the worst and proprietary expensive license and Julia is just not there yet, not by a long long shot.
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🤞
❋ LIST OF CORRECTIONS AND UPDATES - last update 2024-10-26 ❋
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:
► 10:11 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.
► 14:32 As of 0.4.27 (2024-10-25), uv has multiple development groups!
1:54 I gotta say, as a Java developer who only dabbles in python every once in a while, the whole deal with packaging, virtual environments, wheels and so on, has deeply confused me to no end, but after checking out your previous video all the unanswered questions I had in the back of my head have been resolved. Honestly surprised such a well-informed person with entertaining videos like yours has fallen under my radar till now! Instant new sub, hope you keep making videos explaining all these historical aspects about the Python ecosystem in such a concise manner
I'm very glad to hear it did its purpose! The first video should probably have been two, but I suspect the uv angle lured more people in than if it were just about the packaging part. :)
name of the vid, i hav exact same need
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. 😅
Man you have such a good banter, it's fun watching your content and hope to see more of you on here :)
Thank you! And you and I both hope the same thing ;)
Fantastic video! I really think you nailed both the technical and human aspects of this sea change in Python packaging. I especially appreciate how you called out all those giant shoulders the Astral folks are standing on. Ruff and uv are amazing tools and they are great partners in helping guide standards to keep interop, multi-culture, and innovation alive.
Love this content Hynek, funny and informative, and your email newsletter is awesome too :)
Great work Hynek, well presented. Thank you
Was sad and missing pycon UK in Cardiff this year. Was happy to accidentally discover you have a new yt channel!
Same! I fell in love with it last year just to get it ripped away again. :(
So happy I found this channel (first video) I’d say I’m intermediate level so I definitely want to dig through your videos. Thank you!
thank you, thank you, thank you! 😊
I love it - keep being awesome Hynek.
thank you Michael - always great to hear from you! 💜
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!
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 UA-cam 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.
Great video as always! really happy about uv progress recent time, hope we will finally have at least somewhat standard for basic package management needs 😅
Also I really would like to see a video or a blogpost why to write python applications as a packages!
Thanks. A very helpful video that gave answers to all my questions. I'm going to replace pyenv and pip-tools with uv.
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.
The only real issue I've had with uv is that "uv tool"/uvx has a slightly awkward interface compared to pipx. Otherwise, it's been a fantastic improvement over everything that's come before, and I'll be very happy when rye's functionality is fully integrated into it.
I still occasionally do `uvx run CMD` 😬 Supplanting Rye is a major goal, so only a matter of time.
Love your style! Instant subscribe. And a great video. uv it is from now on.
I have been a python fan since the python 1.5 days (and my previous language experience was pre-standard javascript and pre-standard C++, so I always found it quite impressive), but as great as I have always found it, it has often been hard to be a python fan. The build tooling and package management in a lot of other languages is so much better.
Which is why it's now time to celebrate! 🥳
"It automatically installs..." Uh? How? Where? How do I remove crap that some random uv thing automatically installed? How can I see what has been automatically installed? How does the automatically installed things integrate with proper system packages (say, on a debian-based distro)?
Where: `uv python dir`
How to prevent: `UV_PYTHON_DOWNLOADS=never `
How does it integrate: it doesn't, that's the whole point. People have been begging for a decoupling forever. If you don't want that, the the env variable or pass `--no-python-downloads`. I set the variable in all my Docker base images.
There's also configuration files at a project, user and (soon!) system level where you can configure this too.
Cool channel. Happy to find it. Looking forward for nw vids
Thank you; you and I both! 😅
Pip is not replacaeable by uv pip. Order matters with uv pip. Pip probably does but I never managed to recreate it. With uv pip order matters albeit with a clear way how.
so is uv is fully same as python pip,
i have a problem to manage uv in offline machine pls help me anyone
If you need concrete help, I recommend dropping by Astral's Discord; people there tend to be very helpful discord.com/invite/c9MhzV8aU5
very good. i have a doubt, can UV work well with django ??pls let me know
There’s no reason for it to not work with Django. Checkout blog.pecar.me/uv-with-django
@@The_Hynek thanks for your reply. i will try it out
I still have difficulties understanding if i have to create a venv or not in uv.
uv will do that automatically for you
@ awesome!
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.
Wdym by manually symlinking?? I use pyenv + pyenv-virtualenv. The process of starting a new project is as simple as: 1. Create the venv: `pyenv-virtualenv 3.12.1 my-new-project`, 2. Ensure youre in the directory of your new project and then set it as the venv for the project's directory: `cd /some/path/myproject && pyenv local my-new-project`, and then you're ready to go. There's no manual symlinking required, hence why I'm confused by your comment..
"implements the entire Python interpreter as a rust macro" wat
good stuff ❤
So would astral's uv be an alternative to pip... or more like an alternative to nuitka?
Nuitka is a Python to C++ compiler, that's something different entirely. uv is only about packaging Python code and an alternative to Pip (since last video) and/or PDM/Poetry/Rye (since this video).
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.
Nice shirt, man
💛💜
Hi Hynek, good video. Can you make a detailed video of what it does that env+pip+weel+bash doesn't? Because other than the performance improvement, I don't see any other improvement over the default tools. Even the lacking stuff on uv can be done with what we already have. For example, to install development dependencies you just create a dev_requirement.txt and run pip install -r dev_requirements. What am I missing?
Until 0.3.0, it was all speed (see my older video - there's a lot more context). Now, most of what uv adds is comfort and misuse safety. As I say in the video: you can give a project to a total newb and they can run `uv run pytest` and uv takes care of EVERYTHING. They can git pull some updates that update dependencies and `uv run` again, and uv will make sure all updates are applied. This eliminates a lot of problems that plagued teams before.
Finally, to borrow my own words: the cross platform lock file is the crown jewel of post-0.3.0 uv. It's a HUGE deal if you need to develop across architectures like I do (ARM vs Intel) or across operating systems (macOS vs Linux vs Windows). This works for .txt lock files only when the dependencies are exactly the same, which they often aren't. For this you used to have to use PDM and Poetry that come with their own sets of problems.
@@The_Hynek thanks!!!
@@The_Hynek so does uv run do uv sync first then actually run?
For all intents and purposes, yes. If you always use `uv run`, any changes to uv.lock (e.g., a git pull) are applied automatically
@@The_Hynek that's nice. I didn't realize that it joins a lot of tools together into a single one, included automatic git pulls and so on. It greatly simplifies the workflow.
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.
Love this video i subbed and enjoy your technical videos! i would love a workflow video about how you build an application with UV and how you use UVX with it. Or this could be a blog post whatever you prefer! keep it up!!
Thank you! 💛
`uv tools` and `uvx` are tools that you don't use with your own project (that would be `uv run`). They are the replacement for `pipx`: so if you have Python tools that you want to use outside of projects, it manages virtualenvs (and Python versions) for you. For example `uvx --from httpie http httpbin.org/json` or `uv tool install --with tox-uv tox` (and then you can run `tox` in your shell whereever you are).
@@The_Hynek would love migration video .. i think this fit with most people as a challenging usage
while uv init to start a new project is the easiest to do
The problem with migration videos is "migrate from WHAT?" - one of the problems uv is solving is that currently there's virtually an infinite amount of workflows.
So happy not to use attrs, you can't imagine!
Just kidding =) The video has a great pitch, always like the videos despite me not having any idea of how packaging works. I simply use it and it rarely shoots me in the foot.
Liked the experience of rye, if uv creates even better tool - I would happily use it in new projects
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.
🤔that naming might be going to be confusing to google
yeah i usually search for "astral uv"
does this work with Mojo?
Sorry, I don’t know anything about Mojo beyond that it exists and that it‘s from Chris Lattner.
wish there was a comparison done with poetry here
I'm trying my best to follow the rough rule that I don't speak ill of other people's projects which has the unfortunate but inevitable consequence that I'll never speak about Poetry.
can you please comment on uv in systems like nixow
sadly I can't, because I've bounced of NixOS many times. However, I've already heard from Nix friends that they plan on creating something like poetry2nix for uv's - and hopefully eventually Python's official - lock file format.
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.
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.
thanks for wearing the good shirt
Now I feel like now I'll have to match my shirts to my takes!
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 🙌
A binary blob that never breaks? Uhm, yeah that just doesn't exist. Never has, never will.
We have to see things in relation to the reality that we live in. Yes, there’s the heat end of universe. And yes, Go programs compiled on Jammy don’t work on Focal. But relative to the CURRENT jankiness of existing tools, it‘s IMHO fair to use the mild hyperbole of "never".
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.
uv being written in Rust isn't even a problem (as long as it works). Is nodejs written in javascript? No, it isn't. Bam, it's called precedence.
There is a bit of history to this angst in the Python community: large parts used to be written in C and we worked for many years to port them to Python, if possible. Making it more approachable and maintainable. That’s how the Mastodon thread starts, in fact. Starting to add Rust is a step back in that sense, but IMO that isn’t really comparable. But it certainly does feel so for some.
Imho writing tooling for language A in language B is a very bad smell. I get that Rust is a shiny object but now whoever is using the tool is unlikely to understand how to debug and fix the tool. Conversely those writing the tool don't need to understand the target language.
at least show us a codebase, or how its done, so that even beginners can enjoy your content
I cannot open-source our work repositories, but I promise I'll make a video once it's possible to use uv's project workflows for open-source projects (that aren't applications for Docker deployments etc).
Coming from conda…wtf is this video about? I have never been more confused than right now
Conda has a very different scope than Python's packaging - it's closer to a Linux distribution than to an ecosystem packaging solution.
I didn't get a sense of how uv is going to be better or different than rye.
I cannot speak for Astral, but they’re maintaining both right now and made it clear that uv wi take over eventually: github.com/astral-sh/rye/discussions/1342 but not until its “better”: github.com/astral-sh/rye/discussions/1164
Since I don’t use Rye myself, I cannot weigh in on it usefully.
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.
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.
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.
@@The_HynekI like to say that go and python are both awesome for opposite reasons. 😎 This is my first time seeing my channel, but means your a good natured responses got my attention as much as the video. I too have fatigue over Pyphon packaging and dependency management. Pipenv and poetry both gave me some hope, but both let me down. I'll try uv soon, and I expect it will be nice. Unfortunately, I think some of the pain points will never go away because backwards compatibility complicates dependency graph resolution and additionally interpreted languages will always have more unexpected breakages during upgrades. However, I have optimism that Python will remain my second favorite language after Go for a very long time.
@@KevinLydaI think it really depends on what you use it for. I use it for math/physics/viz, for me there is no alternative. MATLAB is literally the worst and proprietary expensive license and Julia is just not there yet, not by a long long shot.
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! 💛
now remove that old video