"Created" not created. It was all done before. You have to be very aware how this tool works as well as there might be some surprises in other venvs on your machine once you tried to mess with your dependencies in one of them for example.
@@CristiNeagu And I have been using it. All my conda environments are now with uv. Actually I stopped using conda install a long time ago. Conda with pip. Now with just the "uv sync" for deployment in a pipeline, you beat conda by a huge margin
Another great feature of UV is its support for UV scripts. The ability to run any Python script without needing to directly install dependencies is fantastic, especially when you want to share it with others.
It works, but I don't like it. Your text editor will complain that the dependencies aren't installed because they're only installed in a temporary environment, so you'll get linting/typing errors and won't have completion.
holy crap, I just asked claude "what is uv and why is my company transitioning to it" hahaha. And an hour later, I see this! You're a legend, Arjan; thank you!
I switched to uv for my latest personal project and I love how fast it is. The biggest problem I found is that if you install software using uv tool instead of pipx for example, the pre-compiled binary distributions of Python that it uses don't play nicely with TK and to a lesser extent matplotlib. The fact that UV is now so popular probably means that lots of developers will have to tackle this problem even if they don't use UV themselves because their users will install things using UV and then think the original project is broken when it doesn't work. The TK issue can be worked around fairly straightforwardly by adding some extra code to your project. Trying to use TK and matplotlib at the same time has proved intractable for me so far.
I like to imagine Astral is funded by Python developers who got rich but also so frustrated by the ecosystem and now angel-fund projects to improve to be proactive about it
Thanks to this channel, I've really stepped up my python coding techniques the past few years, especially when it comes to dataclasses and type hints. Thanks!
Thanks for the video! 2 little thoughts: 1) A good reason for doing the curl install is enabling the uv self update feature. Not sure if that's available with brew install. 2) I know it's not as flexible as npm scripts, but you can do stuff like [project.scripts] my-script = "my_project.scripts:some_function" and pass args via sys.argv etc like `uv run my-script arg1 arg2`
Be aware that the installer needlessly (in my case) modified the .profile and .bash_profile files. Make copies beforehand and compare, especially if you maintain your own profile files.
That's not what he meant by scripts. Actually, project.scripts is a misnomer. Those are the commands that the package export. What he meant was things to standardise commands, so `uv run pytest` could become uv test or something like that, or `uv lint` could be `uv run ruff check --fix && uv run ruff format && uv run pyright`
Thanks arjan! You've been very helpful to the community. I have small request though. please make a small course on how to create production ready application (you could share your workflow and tools you use😝).
I’ve enjoyed using UV and think some of the real gains are in its use with container building. I’d be really keen if you were to do an updated docker build guide with UV.
@@souvidejack package installation isn't completely IO-bound. There is a lot of IO, and uv has some tricks to speed those up, but tools like Poetry spend a lot of time solving the dependency constraints to determine package versions, and that's CPU-bound. Doing it in Rust helps, but they're also really clever about some things. There's a video from Charlie Marsh from Astral discussing these points.
Been using it for the better part of this year for both professional and personal work. It's awesome! It also feels like it solves or simplifies a lot of the complaints devs who don't like Python complain about.
6:50 you could use uv sync if you add manually a package in pyproject or you want to start with a pyproject.toml you use as a template(I use this method) in an empty directory. The advantage of this method is that you have a perfectly compiled pyproject with the settings of the individual tools such as ruff, etc. 15:03 you could use "uv run pytest"
"uv run pytest" only works because it's an existing tool. The scripts listed in package.json for node.js projects are user-defined. So I can have "npm/yarn/pnpm test" to run whichever test framework I like along with any command-line arguments I like. And these can be chained. For example, I have "yarn prepr" in most of my work projects to run linting, unit tests and type checking. It's immensely useful and something that a tool like uv should definitely add.
I'm just about to recommend uv to my colleagues at the next weekly meeting. 😊 The installation process with uv is so fast that I can't even enjoy my usual coffee break while waiting for it to finish.😆
My job requires me to explore many open-source AIGC projects, and the installation of Torch is always extremely time-consuming, though not something I do every day.
I would appreciate more advice about using workspace. We are usually not used to using monorepo approach but there seem to be some benefit - like bundling multiple packages needed for one application. But one has to invent or discover proper "living style" with it.
I’ve been using uv for a few months now. I like that it shortens and simplifies my workflow. I work with many different python projects every day and constantly have to pull down new ones. I like that I don’t have to remember to activate a venv when opening a terminal to a different project. I’ve now also baked it into my pipeline runs which has cut run time down, literally saving money. I am concerned about this company pulling something ugly someday but until then, drink up!
I tried using it for a project from scratch instead of poetry. What I noticed is that UV CLI is not as user friendly as Poetry one (yet). I hope they do improve this with later releases
I find it very straightforward. You do have to keep in mind that uv has extra running modes that poetry doesn't though: most notably standalone scripts, tools (uv tool, like pipx), uv pip, and python interpreter management (uv python). These modes are orthogonal to a project workflow, like the one you have with poetry commands.
What don't you like about it? The only commands you'll use 90% of the type are uv add/remove (which do what's expected) and uv run (which is straightforward). uv sync and uv lock aren't used often because uv run already syncs the environment before running the command.
@@maleldil1 For example, upgrading a package might be a little tricky. In Poetry it is simply `poetry update package_name`, in UV it is more or less `uv lock --upgrade-package package_name`. I have not looked into UV recently, maybe they have changed it
@@dragonoha I find it more helpful to upgrade them all (uv sync --upgrade) and just pin the ones that shouldn't be upgraded, or put explicit version constraints as needed. Upgrading individual dependencies seems finicky.
For now I'm not making the switch, because I quite like Poetry and have no issues with it. If anything I'd need to rework all my CI scripts and project templates to support it, and that's a lot of work with no massive benefit to me. I don't mind it being a little slower, nor do I care about managing Python versions with the same tool. For now.
I will say, I moved my company's repo that's ~100k lines of python where I was previously using Conda to manage my environments to UV, and migrating it + rebuilding the CI (ie deleting most of the CI and replacing with one or two UV commands) only took about a day. Compared to other python configuration tools, it's a lot more streamlined of a setup and migrations involve deleting more code than you add.
12:30 I am also interested in cleaning up all of my different python versions. I some venvs with versions going back to 3.7. What is a safe way to migrate older scripts to new python versions? Similarly, I may more .venv than i need. Any advice?
using conda, we can do something like conda export to export all packages to a gz file so that when we move to a new computer without internet access, we can just unload those packages directly and start working in the exactly same envrionment right away. Is UV capable of doing that?
Very nice video! I think what's missing is the group features (maybe it exists but not covered in your video ^^"). This is a great feature as you don't want to install the mypy package on production environment :)
I think next time you should add some short lines to explain some concepts like workspaces, or tools to less professional users like me. That said, I really liked the video. You were extremely clear, contrary to the documentation I tried unsuccessfully to follow in the first place, prior to resorting to another tutorial when I first discovered UV some time ago.
I switched to uv a few weeks ago and I'm happy with it. Definitely still learning all of the functionality, but it seems cleaner than the default Python tools like pip and virtualenv. Coming from Ruby where rake is widely used for task automation I also missed having a tool like that in Python. I've been using paver, which works OK but seems to be abandoned. E.g. in my project you can run "paver unit" and that invokes pytest. And "paver code" runs black, flake8, and mypy. I'm not sure that task automation functionality should be built in to uv, but I wouldn't mind if it was.
Having already invested a lot in working with Poetry and Pipx, I'm pretty happy with the workflow we have, but I'm going to keep an eye on uv. When they have their own backend, it will be a bit more interesting.
Correct. "uvx pytest" and the program or module you want to test. But you can add pytest to --dev and do a "uv run pytest". Depending what you want to do. I am an absolute novice regarding testing but I do the uvx way.
Coming from python -m venv venv I found uv add --dev ipykernel very good. It just separates development and production modules. The "Declaring script dependencies" feature is also very interesting.
We are using uv for a while. We switched from poetry. I like the speed most and they are following pep standards for pyproject file. Scripts feature is a need as well. I am using poethepoet for it for now.
Does uv have a way of grouping dependencies in the pyproject toml file similarly to poetry? I find that rather useful, as you may wish to have many more dependencies when developing the codebase vs. when you deploy the code in production., Any ideas on that Arjan?
I switched as well as it looks really cool but ran into issues with the tools features where some stuff just doesn’t work properly without forcing it to add the other commands in the package. It also had some compatibility issues so I stopped using it.
14:40: For sure a 17+ min video will not be able to cover each and everything - but it generated a certain level of hunger on it (for it ?) on my end. Actually there was some noise on "uv" lately but your video triggered me to use it as well. Thanks a lot !!! 🙏🙏🙏 15:00: Arjan, didn't you gave rust a try lately ? Sooo: Why don't you implement the "uv test" feature into "uv" to boost "uv" eveen more ? ... 😇
Hi Arjan, thank you for this video on uv I will definitely test it. I did not really understand the usage of "tool", where it is installed, should it replace the "group dev" dependency we have in poetry, or is it just something we want to use locally? Creating dependency groups is very usefull ; from the comments, I guess it has been implemented. Managing Python versions is THE big plus IMO. About the speed I don't see why people care about. When you install deps, it means you don't expect your code to run immediately. Looks like a good start to become a standard. Or poetry strikes back with Python versions management :)
"uv tool" (AKA uvx) replaces pipx. I find pipx's interface for injecting extra dependencies (such as plugins) more convenient than that of "uv tool", but only slightly so. They're super useful for things like Pelican.
Great video. I never adopted poetry because it was really annoying and too different than PIP and pyenv-virtualenv. Wondering why UV defaults repos to master when the default in GitHub and other platforms is now main. This is annoying because now I have to manually rename repos created with UV so that my team and others can push/pull without having to think about branch names. Seriously, why are ENGs so annoying sometimes? Just follow precedent people. And choose your battles. I want to write code, not rename repos because some old head has a problem with no longer using language from early atomic clocks ffs
I switched from Poetry to PDM a couple of years ago and right now I can't really see much reason to switch to UV. The two points I do see are a) it's much faster, b) that ability to install a specific Python version is neat, but there's other ways to do that too. When I first checked out UV I also couldn't figure out how to configure it with my particular usecase with multiple local PyPI indices, but looking at the docs now now I see how to do that, so I might give it a go anyway. It's almost a drop-in replacement for PDM anyway.
I have two questions: 1. How does this play along with VS Code? I use conda, and that is integrated quite well in Code. It knows to load the correct environment both in the terminals I open and in the debugger. Is this an option with uv? 2. Does it manage the installation of complex packages that need things like compilation? It's been a while, but I seem to recall that Numba was a pain to get working unless you used conda. Also, come to think of it, as a result of those two questions: Does uv support conda-forge and conda packages?
Sounds an awesome tool.... I'm starting to build an app with some CI/CD functionalities to deploy it to AWS... I'll take a look in puffin (oops, I mean, UV) to see if that's useful to me...
I only _just_ migrated to poetry .. not a new tool to learn already -_- One thing that is still missing from uv is being able to create pyinstaller builds, which is quite nicely integrated in poetry. Better integration with test suites (like tox) would be really nice and something that poetry and other tools don't have. I'm never an early adopter of technology, so I will probably wait a while to see how the project develops and if we will see some of these improvements included. Until then I'm quite happy with poetry for now.
uv already has over 10% of pypi downloads. At this point I'm confident the community would take over in case something bad happens. It's not a project that is nearly impossible to maintain like a browser engine.
Being VC backed means keep track of your versions very closely, don’t automatically pull updates, star their repos, and be prepared to switch to open source alternatives on a moment’s notice. Don’t depend too much on this tool. VC ecosystem is about making impossible ROI and otherwise milking every project for all its worth even if that includes burning down and liquidating everything. Is UV open source?
I do not think an own build backend should be a priority. Rather a "bundle" to substitute pyinstaller. They take the python installations from what indygreg did, and his pyoxidozer wax a nice thing. I hope they could finish it.
VSCode detects the virtual environment in less than one second after the creation. It asks you to pick it and confirm. In worse case you select it from the list of environments. You probably have old settings for python source in VSCode. You need to delete them if you have them.
@halcyonramirez6469 checkout the benchmark, FireDucks on average is 20-50% faster than Polars, with zero code change/rewrite. You can use existing Pandas code.
@halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed. So anyone can use their Pandas code right away without any rewrite to Polars.
@halcyonramirez6469 @halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed. So anyone can use their Pandas code right away without any rewrite to Polars.
@halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed. So anyone can use their Pandas code right away without any rewrite to Polars.
You compared uvx with pipx but its not quite the same as you said later in the video. I still use hatch until uv is more feature complete. The binary of uv is pretty big (>50MB) also which i dont understand yet. Thank you for the video this is a great tool!
right, but poetry is considering removing poetry shell in v2. It will be a plugin and a similar functionality will be accomplished with poetry env activate. I believe that was done because of the problems of running poetry shell in scripts. The new env activate won't change your shell. uv has an activate command too (correction: it creates an activate script you can source there is no subcommand to activate it), though I do think it's a crutch. Personally I haven't "activated" an env since I started using poetry. `uv run x` and `poetry run python x` are more reliable. Both in interactive shells and in scripts.
This is great but I don't know how useful for me since I moved to nix recently. On the hindsight, I see quite a few projects are moving in the direction of nix to be declarative and reproducible.
a reqs.txt doesn't track transitive dependencies (deps of deps), required python version, locked versions for reproducibility, and upgrading packages is a mess. so yes, I'd use it.
uv still have some weird problems but it's great for 95%+ of people. Like with poetry it doesn't play that well with pre-release packags and if you have dev requirements that need higher python version than mentioned in the package (like doc dependecies) it completely freaks out. I'm sure these will be ironed out at some point. I guess that mostly affects library developers.
Same guys behind Ruff which I switched to and really like. I’m concerned about how a company like this plans to make money and stick around? Is it worth it to learn a tool like this if it’s possible it might be bought up to go bankrupt? I’d that makes sense?
💡 Learn how to design great software in 7 steps: arjan.codes/designguide.
please time tag your videos sir,
About time someone created a single tool to manage Python versions and packages! Thank you for sharing!
"Created" not created. It was all done before. You have to be very aware how this tool works as well as there might be some surprises in other venvs on your machine once you tried to mess with your dependencies in one of them for example.
Conda has been a thing for ages.
@@CristiNeagu And I have been using it. All my conda environments are now with uv. Actually I stopped using conda install a long time ago. Conda with pip. Now with just the "uv sync" for deployment in a pipeline, you beat conda by a huge margin
@@jjrrmm My point was that a single tool to manage python versions and packages already existed.
@@jjrrmm conda is not python specific, so they really occupy different spaces.
Another great feature of UV is its support for UV scripts. The ability to run any Python script without needing to directly install dependencies is fantastic, especially when you want to share it with others.
even python itself is installed if you don't have the right version. And it's fast af.
It works, but I don't like it. Your text editor will complain that the dependencies aren't installed because they're only installed in a temporary environment, so you'll get linting/typing errors and won't have completion.
holy crap, I just asked claude "what is uv and why is my company transitioning to it" hahaha. And an hour later, I see this! You're a legend, Arjan; thank you!
You’re most welcome! 😊
Literally I just had a meeting today talking about uv as well, great timing!
Oh wow! I've been waiting and hoping for a tool like this for ages! Looks great and will start using it straight away. Very cool!
I switched to uv for my latest personal project and I love how fast it is. The biggest problem I found is that if you install software using uv tool instead of pipx for example, the pre-compiled binary distributions of Python that it uses don't play nicely with TK and to a lesser extent matplotlib. The fact that UV is now so popular probably means that lots of developers will have to tackle this problem even if they don't use UV themselves because their users will install things using UV and then think the original project is broken when it doesn't work.
The TK issue can be worked around fairly straightforwardly by adding some extra code to your project. Trying to use TK and matplotlib at the same time has proved intractable for me so far.
We've started integrating uv recently in our project. It is a game changer in python package managers world for sure.
I like to imagine Astral is funded by Python developers who got rich but also so frustrated by the ecosystem and now angel-fund projects to improve to be proactive about it
Thanks to this channel, I've really stepped up my python coding techniques the past few years, especially when it comes to dataclasses and type hints. Thanks!
Glad you find the videos helpful!
Thanks for the video! 2 little thoughts: 1) A good reason for doing the curl install is enabling the uv self update feature. Not sure if that's available with brew install. 2) I know it's not as flexible as npm scripts, but you can do stuff like
[project.scripts]
my-script = "my_project.scripts:some_function"
and pass args via sys.argv etc like `uv run my-script arg1 arg2`
Be aware that the installer needlessly (in my case) modified the .profile and .bash_profile files. Make copies beforehand and compare, especially if you maintain your own profile files.
That's not what he meant by scripts. Actually, project.scripts is a misnomer. Those are the commands that the package export. What he meant was things to standardise commands, so `uv run pytest` could become uv test or something like that, or `uv lint` could be `uv run ruff check --fix && uv run ruff format && uv run pyright`
@@maleldil1 He mentioned the curl installer, which is what I was referring to. Or were you directly replying to the first message in this thread?
This is fantastic1! Just the dependency management alone is worth its weight in gold!
i just got comfortable with poetry
Drop it now
I never tried poetry because i hated the name
uv is really superior
UV doesn't sound as good as poetry either.
Unlike Puffin.
You’ll love uv then
Thanks arjan! You've been very helpful to the community. I have small request though. please make a small course on how to create production ready application (you could share your workflow and tools you use😝).
I’ve enjoyed using UV and think some of the real gains are in its use with container building. I’d be really keen if you were to do an updated docker build guide with UV.
I wonder what would that be. Package installation is io-bound, so any amount of async is acceptible.
Oh that would be wonderful
The uv documentation has as dedicated section on Docker. Maybe that's helpful.
@@souvidejack package installation isn't completely IO-bound. There is a lot of IO, and uv has some tricks to speed those up, but tools like Poetry spend a lot of time solving the dependency constraints to determine package versions, and that's CPU-bound. Doing it in Rust helps, but they're also really clever about some things. There's a video from Charlie Marsh from Astral discussing these points.
@@maleldil1 And how much time exactly said dependency constraint solving in rust saves? Single digit percents, am i right?
Been using it for the better part of this year for both professional and personal work. It's awesome! It also feels like it solves or simplifies a lot of the complaints devs who don't like Python complain about.
6:50 you could use uv sync if you add manually a package in pyproject or you want to start with a pyproject.toml you use as a template(I use this method) in an empty directory. The advantage of this method is that you have a perfectly compiled pyproject with the settings of the individual tools such as ruff, etc.
15:03 you could use "uv run pytest"
"uv run pytest" only works because it's an existing tool. The scripts listed in package.json for node.js projects are user-defined. So I can have "npm/yarn/pnpm test" to run whichever test framework I like along with any command-line arguments I like. And these can be chained. For example, I have "yarn prepr" in most of my work projects to run linting, unit tests and type checking. It's immensely useful and something that a tool like uv should definitely add.
You don't need uv sync. You can just run uv run and it will sync the environment before running the command.
I'm just about to recommend uv to my colleagues at the next weekly meeting. 😊
The installation process with uv is so fast that I can't even enjoy my usual coffee break while waiting for it to finish.😆
Just out of interest, do you install packages every morning? Why?
My job requires me to explore many open-source AIGC projects, and the installation of Torch is always extremely time-consuming, though not something I do every day.
I would appreciate more advice about using workspace. We are usually not used to using monorepo approach but there seem to be some benefit - like bundling multiple packages needed for one application. But one has to invent or discover proper "living style" with it.
That's pretty cool-a bit like a cargo for Python. I like that. Thanks for sharing, Arjan!
I’ve been using uv for a few months now. I like that it shortens and simplifies my workflow. I work with many different python projects every day and constantly have to pull down new ones. I like that I don’t have to remember to activate a venv when opening a terminal to a different project. I’ve now also baked it into my pipeline runs which has cut run time down, literally saving money. I am concerned about this company pulling something ugly someday but until then, drink up!
I tried using it for a project from scratch instead of poetry. What I noticed is that UV CLI is not as user friendly as Poetry one (yet). I hope they do improve this with later releases
I find it very straightforward. You do have to keep in mind that uv has extra running modes that poetry doesn't though: most notably standalone scripts, tools (uv tool, like pipx), uv pip, and python interpreter management (uv python).
These modes are orthogonal to a project workflow, like the one you have with poetry commands.
What don't you like about it? The only commands you'll use 90% of the type are uv add/remove (which do what's expected) and uv run (which is straightforward). uv sync and uv lock aren't used often because uv run already syncs the environment before running the command.
@@maleldil1 For example, upgrading a package might be a little tricky. In Poetry it is simply `poetry update package_name`, in UV it is more or less `uv lock --upgrade-package package_name`. I have not looked into UV recently, maybe they have changed it
@@dragonoha I find it more helpful to upgrade them all (uv sync --upgrade) and just pin the ones that shouldn't be upgraded, or put explicit version constraints as needed. Upgrading individual dependencies seems finicky.
For now I'm not making the switch, because I quite like Poetry and have no issues with it. If anything I'd need to rework all my CI scripts and project templates to support it, and that's a lot of work with no massive benefit to me. I don't mind it being a little slower, nor do I care about managing Python versions with the same tool. For now.
I like what I've seen enough to switch for new projects, but I wouldn't consider switching an existing project to uv.
I will say, I moved my company's repo that's ~100k lines of python where I was previously using Conda to manage my environments to UV, and migrating it + rebuilding the CI (ie deleting most of the CI and replacing with one or two UV commands) only took about a day. Compared to other python configuration tools, it's a lot more streamlined of a setup and migrations involve deleting more code than you add.
Already use uv) Thanks for video!
Switching to UV has streamlined our Pulumi pipelines, making them nearly three times faster than before.
I was wondering when you'd make a video about switching to uv! 😅
It was about time :)
@@ArjanCodes Great overview, as always! I've been using uv for a while but the "uv tree" command was new to me.
Awesome! Used to pyenv. That looks way more handy! Thx for clarifying vid.
Glad it was helpful!
Thanks for sharing this tool i will use it soon 🙂❤
12:30 I am also interested in cleaning up all of my different python versions. I some venvs with versions going back to 3.7. What is a safe way to migrate older scripts to new python versions? Similarly, I may more .venv than i need. Any advice?
using conda, we can do something like conda export to export all packages to a gz file so that when we move to a new computer without internet access, we can just unload those packages directly and start working in the exactly same envrionment right away. Is UV capable of doing that?
Very nice video! I think what's missing is the group features (maybe it exists but not covered in your video ^^"). This is a great feature as you don't want to install the mypy package on production environment :)
I've been enjoying a mixture of hatch and uv for my recent python projects.
So with this I can get rid of both poetry and pyenv? Sounds great to me! Any gotchas I have to know before making the transition?
iirc the gotcha is VC funding and VC aren't charity. at some point they're going to want their investment back
ah, it's mentioned right at the start of the video. at least we can trust this channel ;-)
nice ! thanks for the recomendation I will start to use it as well
Never mention puffin rock again
I puffin…. I mean promise!
Keep mentioning Puffin Rock. It’s funny, and I don’t even know what it is 😂
I think next time you should add some short lines to explain some concepts like workspaces, or tools to less professional users like me. That said, I really liked the video. You were extremely clear, contrary to the documentation I tried unsuccessfully to follow in the first place, prior to resorting to another tutorial when I first discovered UV some time ago.
I switched to uv a few weeks ago and I'm happy with it. Definitely still learning all of the functionality, but it seems cleaner than the default Python tools like pip and virtualenv. Coming from Ruby where rake is widely used for task automation I also missed having a tool like that in Python. I've been using paver, which works OK but seems to be abandoned. E.g. in my project you can run "paver unit" and that invokes pytest. And "paver code" runs black, flake8, and mypy. I'm not sure that task automation functionality should be built in to uv, but I wouldn't mind if it was.
Thanks, Arjan. This was a great overview of uv. The question I'm left with is: what does Arjan have against puffins?!?! 😂
Having already invested a lot in working with Poetry and Pipx, I'm pretty happy with the workflow we have, but I'm going to keep an eye on uv. When they have their own backend, it will be a bit more interesting.
I'm trying to read through the uv documentation right now and all I can hear is Puffin Rock!
Is it FOSS and able to be used commercially for no charge?
15:15 wouldn't that be possible if you were to use uvx though? As long as a tool for it exists.
Correct.
"uvx pytest" and the program or module you want to test.
But you can add pytest to --dev and do a "uv run pytest". Depending what you want to do. I am an absolute novice regarding testing but I do the uvx way.
What arjan meant was that you can setup scripts just like you would do at a package.json … so you can create alias to run custom scripts…
So great stuff!
Should you use uv base image in prod
you can! you should read about python build standalone. depends what prod is
i know many closed source projects that already do, open source is more tricky
Coming from python -m venv venv I found uv add --dev ipykernel very good. It just separates development and production modules. The "Declaring script dependencies" feature is also very interesting.
2:56 that was surprising. Arjan what kind of terminal is that?
We are using uv for a while. We switched from poetry. I like the speed most and they are following pep standards for pyproject file. Scripts feature is a need as well. I am using poethepoet for it for now.
This look very good!
How is it for switching Py versions in vscode? I use Pyenv a lot for that today to have 2-3 diff versions installed.
Does uv have a way of grouping dependencies in the pyproject toml file similarly to poetry? I find that rather useful, as you may wish to have many more dependencies when developing the codebase vs. when you deploy the code in production., Any ideas on that Arjan?
I switched as well as it looks really cool but ran into issues with the tools features where some stuff just doesn’t work properly without forcing it to add the other commands in the package. It also had some compatibility issues so I stopped using it.
14:40: For sure a 17+ min video will not be able to cover each and everything - but it generated a certain level of hunger on it (for it ?) on my end. Actually there was some noise on "uv" lately but your video triggered me to use it as well. Thanks a lot !!! 🙏🙏🙏
15:00: Arjan, didn't you gave rust a try lately ? Sooo: Why don't you implement the "uv test" feature into "uv" to boost "uv" eveen more ? ... 😇
Hi Arjan, thank you for this video on uv
I will definitely test it. I did not really understand the usage of "tool", where it is installed, should it replace the "group dev" dependency we have in poetry, or is it just something we want to use locally? Creating dependency groups is very usefull ; from the comments, I guess it has been implemented. Managing Python versions is THE big plus IMO. About the speed I don't see why people care about. When you install deps, it means you don't expect your code to run immediately. Looks like a good start to become a standard. Or poetry strikes back with Python versions management :)
"uv tool" (AKA uvx) replaces pipx. I find pipx's interface for injecting extra dependencies (such as plugins) more convenient than that of "uv tool", but only slightly so. They're super useful for things like Pelican.
Puffin jingle is now going to live rent free in my head for the rest of my life
I'm trying to use uv in my personal projects. I have a question?
How can I add a private package using extra-index-url?
Very useful, thank you!
Great video. I never adopted poetry because it was really annoying and too different than PIP and pyenv-virtualenv. Wondering why UV defaults repos to master when the default in GitHub and other platforms is now main. This is annoying because now I have to manually rename repos created with UV so that my team and others can push/pull without having to think about branch names. Seriously, why are ENGs so annoying sometimes? Just follow precedent people. And choose your battles. I want to write code, not rename repos because some old head has a problem with no longer using language from early atomic clocks ffs
Real Banger thx😊
Would love to get the vscode theme or color schemes. It looks so clean but elegant. Thanks.
Ideally, a custom Docker image with the bare minimal and uv + zsh preinstalled. A great fit with VScode and dev containers, don´t you think?
Uv is great Arjan, have you also tested pixi as a replacement of conda ?
How do you get all these package manager just use your system packages when available?
So it is adding a layer to something like virtualenv or venv or conda?
thinking how's crossplatform support, say, torch w/wo cuda is already very tricky on poetry. hope uv can resolve this.
Do we need to activate the venv in terminal before adding and removing packages?
No, if you use "uv add/remove " it will activate the venv as part of that call.
I switched from Poetry to PDM a couple of years ago and right now I can't really see much reason to switch to UV. The two points I do see are a) it's much faster, b) that ability to install a specific Python version is neat, but there's other ways to do that too.
When I first checked out UV I also couldn't figure out how to configure it with my particular usecase with multiple local PyPI indices, but looking at the docs now now I see how to do that, so I might give it a go anyway. It's almost a drop-in replacement for PDM anyway.
I have two questions:
1. How does this play along with VS Code? I use conda, and that is integrated quite well in Code. It knows to load the correct environment both in the terminals I open and in the debugger. Is this an option with uv?
2. Does it manage the installation of complex packages that need things like compilation? It's been a while, but I seem to recall that Numba was a pain to get working unless you used conda.
Also, come to think of it, as a result of those two questions: Does uv support conda-forge and conda packages?
I want to know the same details, anybody knows ?
I kind of miss an easy way of opening an interactive python shell within the setup env, do you know if this is a possibility?
Do you mean: "uv run python"?
That should do it.
`uvx ipython` if you're fancy?
Sounds an awesome tool.... I'm starting to build an app with some CI/CD functionalities to deploy it to AWS... I'll take a look in puffin (oops, I mean, UV) to see if that's useful to me...
Compatible with docker containerization?
Of course why not?
How do you feel about the Hatch project?
Interested in diving into Polylith for Python? There is a new uv mode for the tool
Can you ask uv to create a test directory package for you?
In the past I've had a devil of a time getting pytest to recognize files in the parent directory
I only _just_ migrated to poetry .. not a new tool to learn already -_-
One thing that is still missing from uv is being able to create pyinstaller builds, which is quite nicely integrated in poetry.
Better integration with test suites (like tox) would be really nice and something that poetry and other tools don't have.
I'm never an early adopter of technology, so I will probably wait a while to see how the project develops and if we will see some of these improvements included.
Until then I'm quite happy with poetry for now.
Being VC backed means they will have to become profitable at some point.
Exactly what I was thinking. It's not wise to use it in commercial production because we don't know what direction the company will go
uv already has over 10% of pypi downloads. At this point I'm confident the community would take over in case something bad happens. It's not a project that is nearly impossible to maintain like a browser engine.
Being VC backed means keep track of your versions very closely, don’t automatically pull updates, star their repos, and be prepared to switch to open source alternatives on a moment’s notice. Don’t depend too much on this tool. VC ecosystem is about making impossible ROI and otherwise milking every project for all its worth even if that includes burning down and liquidating everything. Is UV open source?
What’s the best way to use UV with Jupyter notebooks?
I do not think an own build backend should be a priority. Rather a "bundle" to substitute pyinstaller. They take the python installations from what indygreg did, and his pyoxidozer wax a nice thing. I hope they could finish it.
I ran into a lot of issues with uv. Mostly surrounding VSCode detection of uv venv. Went back to using python for now.
VSCode detects the virtual environment in less than one second after the creation.
It asks you to pick it and confirm. In worse case you select it from the list of environments.
You probably have old settings for python source in VSCode.
You need to delete them if you have them.
Bit by bit, functionality in Rye is making its way into uv, and custom scripts will likely be one such piece of functionality.
Next topic suggestion: FireDucks ~ Pandas but 100x faster.
Polars is already a 100x faster than pandas
@halcyonramirez6469 checkout the benchmark, FireDucks on average is 20-50% faster than Polars, with zero code change/rewrite.
You can use existing Pandas code.
@halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed.
So anyone can use their Pandas code right away without any rewrite to Polars.
@halcyonramirez6469 @halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed.
So anyone can use their Pandas code right away without any rewrite to Polars.
@halcyonramirez6469 look up some benchmark, FireDucks is overall even faster than Polars. And the best thing is zero code change needed.
So anyone can use their Pandas code right away without any rewrite to Polars.
Version bump is missing
Something tells me Arjan likes puffin more than uv
You compared uvx with pipx but its not quite the same as you said later in the video.
I still use hatch until uv is more feature complete.
The binary of uv is pretty big (>50MB) also which i dont understand yet.
Thank you for the video this is a great tool!
"uv lock --upgrade" Upgrade all the packages.
"uv lock --upgrade-package openai" Upgrade a specific package.
Thank you for "puffin"
How does UV compare with Pixi?
but there is no equivalent to "poetry shell" right?
right, but poetry is considering removing poetry shell in v2.
It will be a plugin and a similar functionality will be accomplished with poetry env activate. I believe that was done because of the problems of running poetry shell in scripts. The new env activate won't change your shell.
uv has an activate command too (correction: it creates an activate script you can source there is no subcommand to activate it), though I do think it's a crutch. Personally I haven't "activated" an env since I started using poetry. `uv run x` and `poetry run python x` are more reliable. Both in interactive shells and in scripts.
This is great but I don't know how useful for me since I moved to nix recently. On the hindsight, I see quite a few projects are moving in the direction of nix to be declarative and reproducible.
Do I need uv? I just use requirements.txt with docker
a reqs.txt doesn't track transitive dependencies (deps of deps), required python version, locked versions for reproducibility, and upgrading packages is a mess.
so yes, I'd use it.
uv still have some weird problems but it's great for 95%+ of people. Like with poetry it doesn't play that well with pre-release packags and if you have dev requirements that need higher python version than mentioned in the package (like doc dependecies) it completely freaks out. I'm sure these will be ironed out at some point. I guess that mostly affects library developers.
I've been using poetry for some times now, and would love to see a way to convert a poetry project into a uv project. Thanks!
VCs will definitely pull the rug lol. pipenv ftw.
i still don't like most dependency managers, like, just write a requirements.txt?? freeze the versions??
Same guys behind Ruff which I switched to and really like. I’m concerned about how a company like this plans to make money and stick around? Is it worth it to learn a tool like this if it’s possible it might be bought up to go bankrupt? I’d that makes sense?
Risk-free life is unsustainable.
Rust ist so awesome that it makes other languages even cooler! UV rocks!
Fully on uv now, switched from pyenv.
My team thought I was crazy when I switched us to UV over a year ago
Does it support groups like poetry?
Yes, but unlike poetry it’s standardized. (PEP 735)
currently tryna set up a docker container with pytorch using uv and I'm going insane.
great now everytime I type uv I will have the puffin rock jingle in my head
It's more or less a faster version of pipenv. If you know one of them you more or less know both.