- alias download_mp3="uvx --no-cache --from yt-dlp[default] yt-dlp --extract-audio --audio-format mp3" to download sound from Youtube videos, SoundCloud pages, etc. This update yt-dlp every time, which is required given the counter measures change so often and the dl rarely affect the total processing time anyway (requires ffmpeg).
- "uvx --with <package> --with pyqt5 --from qtconsole jupyter qtconsole" starts a qtconsole (GUI version of ipython) with <package> installed so you can test it quickly. Temp venv, everything cached so next time it's instant, one single copy of pyqt5 for the current use no matter how many times you run those.
- "uvx --with virtualenv pipx run pipsi install nodejs-bin". Ok it's useless, but it's fun that it even works :)
uv's cache system and downloads optimization are quite smart, as Charlie marsh (astral CEO) explains in the interview: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...
Or points to your own private pypi instance with --index-url.
Startup times has to be slower, but probably only for the first run?
There's a some level of violation of the "Principle Of Least Surprise", depending on the setting. For some it will be the reverse, the script they got just works, without any setup or package installation. For others we'll wonder why it just started downloading a bunch of packages we already have.
Probably not the greatest idea for production environments, where you should not or can not just pull in packages from the internet.
It's really cool that it works, but I think I'd recommended using it highly selectively.
The problem with that is that eventually too many scripts means you will hit incompatibilities in Python where you can only install one version of a lib in each venv.
This trick is perfect because:
- From now on, I always install uv on all my machines anyway.
- After the first run, not only the cache make it fast, but it uses hard links so that you don't even pay the of multiple install on disk space (that's also how they are so fast in creating the envs, that and some interesting HTTP/zip tricks: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...).
- Deps are clearly defined in the script, so it's self-documenting.
For prod, shiv (https://shiv.readthedocs.io/) is probably your best bet but I'm betting uv will come up with a version of that soon.
Do you have any good sources for learning shiv? The docs are very sparse & lack examples and there aren't as many blogs discussing shiv as I'd hoped.
Also, do you know if shiv works on Windows?
But yes, unlike pex, shiv works on windows.
It's very different than pyinstaller in the sense that:
- it uses a standard (the zipapp format from python stdlib)
- it assumes python is already installed (it's not stand alone)
I definitely should write on article on that on Bite Code on day. Adding it to the list.
It's slow on every run because it has to build the python virtual environment every time, even if it's cached all the packages
(Mainly through tricks involving hard links)
Nor for any system where one takes care to not needlessly increase the threat surface.
https://peps.python.org/pep-0723/
I've been very slowly migrating scripts to work with this, and `pipx run`. glad to know uv has also picked it up.
What's the advantage of this that makes it worth despite these constraints, compared to e.g. using pyinstaller [1] to build and distribute a single executable file with the python interpreter and all the dependencies of your project bundled in it in the exact versions you chose in your development virtual environment?
this makes everything SO much easier.
> A single tool to replace pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more.
#!/usr/bin/env -S uv run -q --no-project --python ">=3.12" --with "openai"
> Code from this PR [1] by David Laban.
That leverages the features of uv run with embedding script dependencies [2].
[1] https://github.com/alsuren/sixdofone/pull/8 [2] https://docs.astral.sh/uv/concepts/projects/run/#running-scr...
Not to shit on anyone's hard work, but how is Python the only popular language whose package management situation is always actively getting more complicated?
I used to love Python, but I won't touch it anymore because I just don't have it in me to learn what the new idiomatic package management practices are in any given Python ecosystem.
For any aspiring language designers out there - take good notes about what happens if you don't bake package management into the official tooling.
Sometimes if you reinvent the wheel enough times you eventually get a round one.
I don't think it is? Did javascript suddenly get boring when I looked away?
> I used to love Python, but I won't touch it anymore because I just don't have it in me to learn what the new idiomatic package management practices are in any given Python ecosystem.
While people keep trying to invent newer better options, you can in fact manage 95% of cases with just pip+virtualenv. (Granted, the other 5% is a quick descent to madness, usually courtesy of non-Python integrations.)