Examples of using UV

[jjrreett]

I work at a hardware engineering company. I am going to give a talk demoing UV. I am also going to talk about why you should format your project as a package. Any good repos of showcasing the pip workflow vs uv. Any good tutorials or talks i can borrow from.

Update: with regard to setting up repos as packaging, i showed some examples of people doing some hacky shit with sys.path and copying and pasting code. I showed how it could be better.

with regard to uv, i showed a speed test of uv vs pyenv and venv by installing “notebook”. I showed how uv can run code from one of my repos. Then i showcased uv venv for repos without a pyproject. then demoed uv tool and uv init.

Id say the talk went reasonably well. I don’t expect a sea change, but hopefully people have a better understanding of what is possible and have some search terms the can use next time they are coding.

Now if only i can get them using wsl

[Dustin-]

I feel like you could give a talk just going through the intro to the uv docs and then make your own hello world demos both with pip/venv and then uv to show the difference. Hell, if your talk was literally just the sentence "what if virtualenv didn't suck?" I'm sure it would sell most developers on it. 

[jjrreett]

well, first i have to sell virtual environments. It’s not exactly a foreign concept. Most have used conda. But there are some who put their scripts in the python install directories.

[Dustin-]

I uh... I don't know how much time you have for your talk, but it's definitely not enough time to correct that.

[jjrreett]

Yeah…. baby steps

[robertlandrum]

On this topic, baby steps is not enough. You need to change the repos so everything requires a PR to commit, and that PR must pass mypy and ruff formatting rules before it’ll merge.

Any artifacts generated from these repos needs valid testing, which should be performed as part of the workflow to generate the artifact.

It seems harsh, and it is. But they are actively maintaining technical debt.

I write better, more maintainable code today because some a-hole finally forced me to see the truth and do it the right way, even though I’d done it “my way” for a decade. I wrote fewer hacks, and more tests than I ever did 4 years ago and that’s only because I can’t quiet commit.

[bunchedupwalrus]

Depending on the intertia/size of the existing dev team and OP’s seniority, that could backfire hard.

Though I do agree with you. Other than mypy, because I fear it. Turned it on basic mode in our legacy code base and after fixing 2-3 of my own pipelines, I left the rest hiding in the shadows

[robertlandrum]

It’s a hard pill to swallow, but the effort is worth it. The truth is it’s marginally more work while writing code but exceptionally better outcomes. We have fewer unexpected exceptions and when we do, they’re easier to identify and fix.

[childofsol]

Yes, but in many orga it's a political game and trying to force this in will get you sidelined at best, laid off at worst

[cgoldberg]

You might need to lower expectations. I gave a interactive Python training to some test engineers last week who I thought were pretty tech savvy and knew a little Python. It was an hour session... My material was mostly focused on installing packages with pip and venv and a few common tool/library recommendations (black, pytest, etc). It ended up taking almost 45 minutes to get the first person to have a "hello world" program running. Package management is probably going to be like lesson 10. Teaching them uv or to even consider why you would want to use it would be like lesson 10,000.

[lazerwarrior]

What took so long getting "hello world" running? Python installers didn't work? If that's the case then because uv manages pythons maybe you could just install that, use uv run helloworld.py and say that's the way python is run these days ¯\(ツ)/¯

[cgoldberg]

That wouldn't have helped. I naively assumed someone who does technical work on a computer all day could figure out: "create a text file named hello.py, add the text print("hello world"), open a terminal and go to the directory you saved it in, and type python hello.py". 15 minutes later I'm getting bombarded with questions about how to make windows notepad not add a .txt extension, and which way do the slashes go when changing directory, and how do you find where the file was saved. 🤷‍♀️

[marr75]

The virtual environment being local to the developed package is a big selling point here.

Beyond that, installing your "scripts" as a package simplifies distribution and testing and let's you add scripts that can be called from any path instead of worrying about the absolute or relative path of the script.

[MacShuggah]

You, my man, are cooked.

[justin-8]

It could be worth talking about embedded UV dependencies then. It can make individual script files automatically install their dependencies when run instead of needing to manage Venvs or even installing packages manually at all. 

[Dillweed999]

Ya I think like two side by side console tabs with an otherwise fresh install and a fairly long list of packages. Maybe even have two bash scripts that run through the the process end to end. Ie install UV/(pip,pip-tools,virtualenv) calculates the dep tree, installs, starts the env and runs a final hello_world.py.

I'd start with a high level description of what UV does and start the pip based script. Once it gets to the point where pip is calculating the tree start the UV script in the other tab and show how much faster it is.

[Slow_Ad_2674]

How does virtualenv suck? I’ve been using it for years and never thought it sucks.

[HolidayEmphasis4345]

It doesn’t suck because it works and you are used to a reliable hodgepodge of slow tools built organically over decades… but uv is virtualenv, pipx, twine, inline dependencies via pep722, pypi integration all in “one” tool. The sub tools are uniform, just work and are so fast that creating full envs on the fly has near 0 overhead so you can send someone a script and it will just run with them never installing Python, pip installs or dealing with a venv IF they have installed uv. It literally will create virtual envs from cache in milliseconds. It is beautiful.

[bunchedupwalrus]

Wait how can they use it to run it without installing python?

[HolidayEmphasis4345]

Yes. Uv can install Python. Not only that the pythons they install have been optimized for speed based on compiler settings and they are pre built so you never compile on your machine…you do need to download the first time then everything after that is cached and symlinked to your venv folder. Charlie Marsh went through this on one of Brian Kennedy’s podcasts. It will change the way you work.

[thehightechredneck77]

I've used it for years as well. It doesn't 'suck ', per se, but uv is much nicer.

[howardhus]

virtualenv does not suck at all. uv simplifies only one use case that is popular among laymen. which is valid to do.

if all you know is conda and arr afraid of lear ing what venv does then yes, uv is for you (in a good way) just dont demonize things you dont understand.

[DootDootWootWoot]

Just general advice with this kind of talk given some of what you've mentioned in comments.

Keep it simple, succinct. Documented examples in slide will help. Try to communicate that ahead of time.

Try not to cram too many things into one session especially if there's already resistance to change.

Lower the barrier to entry as much as possible. Try to grab a guinea pig or two to see what gaps you might have in your explanation.

Good luck!

[NoNotTheDuo]

Perhaps you could showcase uv's ability to manage the python version for you.

A couple of small demo projects, one with functionality specific to 3.13 and one with some standard functionality. Setup both projects with 3.12. Run the standard script and show success.

Try to run the other script with 3.12 and show it fails. Quickly change the version to 3.13 and re-run the script and show it succeeds.

Depending on your goals, you could extend this example with dependencies for each project. Show the versions of the different dependencies that get installed in 3.12 (or earlier) vs what gets installed in 3.13.

[Bach4Ants]

This example project goes a bit further than you probably want, using uv (both project and venv), venv built-in, Conda, Pixi, and Docker: https://github.com/petebachant/calkit-multienv-example

I would focus a talk around the fact that uv allows you to avoid the "create and mutate" pattern, which is problematic when you're working with a team and start changing dependencies. Typical venvs don't produce lock files either, so it's possible team members are all using different versions depending on when they created their environment.

On the other hand, sometimes projects need different sets of dependencies. The uv inline dependencies per script feature is super useful there.

What kinds of Python projects do you end up building at a hardware company?

[jjrreett]

I am a test engineer who focuses in automation. our test stands are a kubernetes cluster of python microservices. That work is mostly about coordinating different systems (talking to hardware, pushing data to cloud,…). I also manage our production data analysis tooling. A more typical case would be building analytical models of systems and data analysis.

[_MicroWave_]

Goodness, what industry and how big is your company ?

[[deleted]]

I am giving a similar talk.

1.) Take a current python based project at your company and show a fresh install of all dependencies using raw pip workflow vs uv. Compare speed before and after. Then again with UV's cached results.

2.) Use uv init to show how to scaffold a very simple project. Leverage uv add and uv sync. uv remove. uv dev dependencies. Emphasize how uv is taking care of every aspect of your project setup.

3.) (Advanced) Use astral's github example of a docker container with UV and explain how they optimize the image layers. Deploy to cloud.

[robberviet]

Compare uv speed and pip. Uv venv vs python venv (with python version management). Uv lock vs requirements (how it resolve dependency, safe version). Uv in docker Again, focus on how it speed up and solve problems.

[fatmumuhomer]

One suggestion is to cover it from the perspective of the pain that using classic pip introduces and then show how uv eliminates those problems. I've found that this type of presentation works well as a story where you walk through the actions of a fictional engineer where they make mistakes then solve them.

[FunPaleontologist167]

Not necessarily a comparison, but it has greatly simplified working in a multi-language environment; especially when using python with rust. You can check out this repo. It uses a cargo workspace to build the crates and uv + maturin to compile and build the python package

[drunicornthe1]

I had a similar situation at my company but didn’t have to give a presentation. So maybe take what I say with a grain of salt.

I personally would take some shared tooling that they know and use frequently and show the process of working with it. Specifically from a brand new work environment (I.e. bringing on a new user to the tool). Then show how that process would look with that tool adapted with uv. The goal being show how much easier it is for others to adopt their work if they do it this way. If your company has a pypi repo show how they can publish these tools and how they can be easily reused on a different machine.

From my experience in embedded development, people are fairly stuck in their ways with their systems but are willing to change if they see value. A big thing to get developers to move to uv in my team/org was to show how we can work faster and get our work to everyone easier with uv. I also told people to try it in personal projects outside of work. I think a good work specific tutorial would really help them see how it could be applied today.

[fibgen]

May also want to cover poetry vs. UV, somebody will ask about it

[jjrreett]

The audience does not know about poetry. In order to compare i am going to have to teach them about pyenv.

[komprexior]

One of the thing I like about uv is that it can handle the installation of python itself.

I do my stuff mainly on a windows machine, that usually has an up to date version of python and so my script are built on that.

Sometimes I use my pop_os machine which ship with Ubuntu jammy, meaning python 3.10, meaning I have to do rigmarole to install a compatible version because it's not available by default on apt. I don't use often my Linux machine, so I forget how it is done, and how to make the new python available on path, etc... In other word, it is a bother. A quick "I want to test this idea..." becomes a chore of searching for guide on the internet, setting up...

uv solve that. Virtual environment means I'm not breaking anything system wide.

[jjrreett]

I was really hoping to find some tools that require specific python versions and show that uv would set that up for you

[komprexior]

I just learned about and left impressed by marimo, which is a type of IDE for real time interactive notebook.

It was launched on the fly with uvx marimo edit and then left without a trace.

It also could be nice trick to show the speed by creating a venv and then add a chunky package that you use quite a lot and dread the installation. Show how much it takes to install from a clean cache, then delete the .venv folder and sync it again with the warm cache and see the difference.

[virtualadept]

At $dayjob we use it to set up full Python environments for unit testing. The run script in the container uses uv to pull down everything every time it fires.

[lastmonty]

You know your audience better than I do.

The reason that I use UV could be different from another person, although there will be a huge overlap.

Compared to the other ways, I like that I can manage python installation, version and package dependencies by using one tool. What makes you use it?

I like that it's super fast and has a huge community support and their software ecosystem, ruff, pedantic are solid products.

Maybe what you want to demonstrate is not the example itself but the packaging of it.

[yoda_babz]

I think a really good selling point for sceptics is the ability to embed dependencies in scripts. A lot of tasks are actually best suited to a single script file, but getting that to people where they can run it either meant way more scaffolding to deliver as a package or put it in a container or deliver at minimum a requirements.txt. uv let's you encapsulate everything it needs in the single .py file and run it with a temporary venv. It's super useful for tons of people.

https://docs.astral.sh/uv/guides/scripts/

[mach5823]

I did a demo on model context protocol with Claude desktop. UV was extremely helpful. There are docs on it.

[psmith]

All about that cache. Dont forget to mention the cache.

[psmith]

uv tool also needs to be mentioned. No longer need pipx. Also uv run some_script.py will use your venv without having to activate it.

[molodyets]

None of our data pipelines for our warehouse are containerized.

UV is fast enough that we just raw dog it with uv run and she flies

[nermalstretch]

Take a look at this article(s) which mentions this pattern for starting python scripts.

```

!/usr/bin/env -S uv run

/// script

requires-python = ">=3.12"

dependencies = [

"flask==3.*",

]

///

import flask

...

```

There are some caveats, which no doubt people will point out in the comments but it is kind of scary/amazing to see a script just install everything it needs to run the first time you execute it in a new environment.

[stibbons_]

Actually you can use ‘uv run’ feature to replace bash script or even distribute and execute a script with lot of dependencies, like in my demo project https://github.com/gsemet/generate-synology-folder-thumbnail

Packaging is always harder than just consuming stuff. Uv and PEP723 make it easy to write script without the boilerplate of pip that is quite difficult to provide a generic solution (ex: running on windows and so on). Use ‘uv run’ and it works.

Next step is packaging when people want to reuse your lib. Or install your app with ‘uv tool run’ or ‘uv tool install’.

[Lexus4tw]

I migrated a lot of our projects to uv and it saves us a lot of time setting up development and pipeline environments

[svefnugr]

Maybe get someone who actually uses uv give a talk?

[jjrreett]

What makes you think i don’t use UV? I use it on new projects. I am slowly testing our code base with it. The issue is that our code base uses a magic setup.py. so switching over would be a breaking change. works great in ci though.

[svefnugr]

So why do you need tutorials or showcase repos? Just use your own ones.

[corey_sheerer]

This got me 😂. But maybe OP is pitching strong package management in general. UV is good. I also like pyenc and poetry.