"The point of performance is not to do the same thing you were already doing but faster. The point of performance is to change the way you work" - Linus Torvalds during initial Git presentation at Google
I just started using uv in my day to day projects and it is amazing. Cool to see that once the limitations of tools are dropped python gets even more useful :)
Started using uv day-to-day 2 weeks ago, and it's already an integral part of my workflow. Can't imagine ever going back to "just" pip. The tools for CI/CD is also very nice! God I hope this product (project?) lasts!
Thank you for sharing your wisdom. What would be really cool while writing in Python is if when working in jupyter lab notebook or an ide eg vscode, pycharm, etc. that when you hovered over a class, function, variable and other types that it gives you a nice representation of the input and output
Jupyter has a feature for that called the contextual helper. This old talk of mine has a demo here: ruclips.net/video/yXGCKqo5cEY/видео.htmlsi=3X-t8-23iEGb_zn5&t=293
So, it's like yarn of the NodeJS world where npm was knocked off the pedestal by it. I like the uv run --with. That's very handy to not be installing other dependencies for some helper scripts.
Am I wrong to see "uv run" usage as a type of "Nix-Shells" capability for Py Envs? Its an abstracted POV, but after seeing people fall out of romance with Poetry, an all-in-one py management tool needs to do more than "venv and pip wrap", especially now with wheeling. This might actually give me a reason as a system designer to get away from the microservice spaghetti monster masquerading as a version manager when looking for adaptive system builds... without learning a new language or distro-locking the OS base! Thank you for showing the use cases useful for more than click bait.
I don't know uv that well, but I thought uv was a lot like cargo, which means it should automatically detect a project and adopt the project's environment, meaning `uv run` automatically adopts the venv...? Correct me if I'm wrong, but if I was not wrong, then why use `source ./.venv/bin/activate`...?
You're correct. If you always only use `uv run ...` from within a uv project directory, then you don't need to activate the venv. However, if you want to run any commands from the venv directly without `uv run`, or if you want run things from outside a project directory, that's when you need to activate the venv.
I haven't used Poetry much, but now that uv exists, I doubt I ever will. Poetry pretty much was only a good solution because nothing better existed several years ago. It deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even the most basic Python project settings, like specifying dependencies, are done differently in Poetry compared to "everyone else" - uv, pdm, hatch, even the PEP standard. If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
I haven't used Poetry much, but now that uv exists, I doubt I ever will. Poetry pretty much was only a good solution because nothing better existed several years ago. It deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even the most basic Python project settings, like specifying dependencies, are done differently in Poetry compared to "everyone else" - uv, pdm, hatch, even the PEP standard. If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
Poetry deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even basic Python project settings like specifying dependencies are done differently in Poetry compared to uv, pdm, hatch, even the PEP standard. If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
"The point of performance is not to do the same thing you were already doing but faster. The point of performance is to change the way you work" - Linus Torvalds during initial Git presentation at Google
Good quote!
I just started using uv in my day to day projects and it is amazing. Cool to see that once the limitations of tools are dropped python gets even more useful :)
The first part of the course is out by the way!
calmcode.io/course/uv/pip
This is a great trick! Love your stuff :)
Totally!
Very crafty! Thankyou for sharing this.
Beautiful! Thanks for sharing!
Started using uv day-to-day 2 weeks ago, and it's already an integral part of my workflow. Can't imagine ever going back to "just" pip. The tools for CI/CD is also very nice! God I hope this product (project?) lasts!
Yeah same, pip is getting phased out more and more on my end.
what are the ci/cd tools for uv and why do you like them?
Thank you for sharing your wisdom. What would be really cool while writing in Python is if when working in jupyter lab notebook or an ide eg vscode, pycharm, etc. that when you hovered over a class, function, variable and other types that it gives you a nice representation of the input and output
Jupyter has a feature for that called the contextual helper.
This old talk of mine has a demo here:
ruclips.net/video/yXGCKqo5cEY/видео.htmlsi=3X-t8-23iEGb_zn5&t=293
@@calmcode-io Thank you 😀
So, it's like yarn of the NodeJS world where npm was knocked off the pedestal by it. I like the uv run --with. That's very handy to not be installing other dependencies for some helper scripts.
Totally!
According to the benchmark results, looks like version 1.5 was also written in rust, like uv :) just kidding :) cool video!
hopefully there is a more official support for benching between versions
Your voice matches your channel name, something about it makes me really calm!
It've had a lot of practice ... calmcode.io ;)
the scripts idea is really nice, but you should consider locking your versions so that they keep working into the future.
Yeah that's fair. Especially when you combine it with a Python version that remains set.
Really cool!
Am I wrong to see "uv run" usage as a type of "Nix-Shells" capability for Py Envs? Its an abstracted POV, but after seeing people fall out of romance with Poetry, an all-in-one py management tool needs to do more than "venv and pip wrap", especially now with wheeling. This might actually give me a reason as a system designer to get away from the microservice spaghetti monster masquerading as a version manager when looking for adaptive system builds... without learning a new language or distro-locking the OS base! Thank you for showing the use cases useful for more than click bait.
I am not familiar with nix, so I cannot make the proper comparison. In short though: yeah UV is super!
I don't know uv that well, but I thought uv was a lot like cargo, which means it should automatically detect a project and adopt the project's environment, meaning `uv run` automatically adopts the venv...? Correct me if I'm wrong, but if I was not wrong, then why use `source ./.venv/bin/activate`...?
I am unfamiliar with cargo so I can't fully answer the question.
You're correct. If you always only use `uv run ...` from within a uv project directory, then you don't need to activate the venv. However, if you want to run any commands from the venv directly without `uv run`, or if you want run things from outside a project directory, that's when you need to activate the venv.
Is there a reason why you use uv pip install requests vs uv add requests?
Mainly for tutorial purposes. I am not dealing with a project here, so no need for pyprpject.toml
Could u please Compare UV with poetry ??
I can't, never really used it.
I haven't used Poetry much, but now that uv exists, I doubt I ever will. Poetry pretty much was only a good solution because nothing better existed several years ago. It deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even the most basic Python project settings, like specifying dependencies, are done differently in Poetry compared to "everyone else" - uv, pdm, hatch, even the PEP standard.
If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
I haven't used Poetry much, but now that uv exists, I doubt I ever will. Poetry pretty much was only a good solution because nothing better existed several years ago. It deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even the most basic Python project settings, like specifying dependencies, are done differently in Poetry compared to "everyone else" - uv, pdm, hatch, even the PEP standard.
If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
Poetry deserves a lot of credit for pushing the concept of `Python projects` forward, but a lot of the concepts it pioneered or popularized are now officially "part of Python" via various PEPs and are implemented by a number of tools such as uv. Unfortunately, since poetry had to do a lot of its magic via non-standard `pyproject.toml` extensions (because the "standard" ones didn't exist yet), nowadays Poetry is basically a relic. Even basic Python project settings like specifying dependencies are done differently in Poetry compared to uv, pdm, hatch, even the PEP standard.
If you already have a large project using Poetry, just keep using Poetry. But if you're starting anything new, or even if you have a relatively small project using Poetry already, you really should be looking at uv.
Really cool!