9 ms·

Fun with uv and PEP 723

640 points by deepakjois 1y ago

korijn 1y ago
There's no lockfile or anything with this approach right? So in a year or two all of these scripts will be broken because people didn't pin their dependencies? I like it though. It's very convenient.
- rahimnathwani 1y ago
  PEP 723 allows you to specify version numbers for direct dependencies, but of course indirect dependencies aren't guaranteed to be the same.
- js2 1y ago
  > There's no lockfile or anything with this approach right? There are options to both lock the dependencies and limit by date: https://docs.astral.sh/uv/guides/scripts/#locking-dependencies https://docs.astral.sh/uv/guides/scripts/#locking-dependenci... https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...
- zahlman 1y ago
  > So in a year or two all of these scripts will be broken because people didn't pin their dependencies? People act like this happens all the time but in practice I haven't seen evidence that it's a serious problem. The Python ecosystem is not the JavaScript ecosystem.
  - nomel 1y ago
    I think it's because you don't maintain much python code, or use many third party libraries. An easy way to prove that this is the norm is to take some existing code you have now, and update to the latest versions your dependencies are using, and watch everything break. You don't see a problem because those dependencies are using pinned/very restricted versions, to hide the frequency of the problem from you. You'll also see that, in their issue trackers, they've closed all sorts of version related bugs.
    - zahlman 1y ago
      > An easy way to prove that this is the norm is to take some existing code you have now, and update to the latest versions your dependencies are using I have done this many times and watched everything fail to break.
      - nomel 1y ago
        Are you sure you’re reading what I wrote fully? Getting pip, or any of them, to ignore all version requirements, including those listed by the dependencies themselves, required modifying source, last I tried. I’ve had to modify code this week due to changes in some popular libraries. Some recent examples are Numpy 2.0 broke most code that used numpy. They changed the c side (full interpreter crashes with trimesh) and removed/moved common functions, like array.ptp(). Scipy moved a bunch of stuff lately, and fully removed some image related things. If you think python libraries are somehow stable in time, you just don’t use many.
        zahlman 1y ago
        ... So if the installer isn't going to ignore the version requirements, and thereby install an unsupported package that causes a breakage, then there isn't a problem with "scripts being broken because people didn't pin their dependencies". The packages listed in the PEP 723 metadata get installed by an installer, which resolves the listed (unpinned) dependencies to concrete ones (including transitive dependencies), following rules specified by the packages. I thought we were talking about situations in which following those rules still leads to a runtime fault. Which is certainly possible, but in my experience a highly overstated risk. Packages that say they will work with `foolib >= 3` will very often continue to work with foolib 4.0, and the risk that they don't is commonly-in-the-Python-world considered worth it to avoid other problems caused by specifying `foolib >=3, <4` (as described in e.g. https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ). The real problem is that there isn't a good way (from the perspective of the intermediate dependency's maintainer) to update the metadata after you find out that a new version of a (further-on) dependency is incompatible. You can really only upload a new patch version (or one with a post-release segment in the version number) and hope that people haven't pinned their dependencies so strictly as to exclude the fix. (Although they shouldn't be doing that unless they also pin transitive dependencies!) That said, the end user can add constraints to Pip's dependency resolution by just creating a constraints file and specifying it on the command line. (This was suggested as a workaround when Setuptools caused a bunch of legacy dependencies to explode - not really the same situation, though, because that's a build-time dependency for some packages that were only made available as sdists, even pure-Python ones. Ideally everyone would follow modern practice as described at https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-python/ https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-... , but sometimes the maintainers are entirely MIA.) > Numpy 2.0 is a very recent example that broke most code that used numpy. This is fair to note, although I haven't seen anything like a source that would objectively establish the "most" part. The ABI changes in particular are only relevant for packages that were building their own C or Fortran code against Numpy.
jkingsman 1y ago
uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Python scripts from Github super easily. No git clone, no venv creation + entry + pip install. And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than pip. It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheless.
- lxgr 1y ago
  Truly. uv somehow resolves and installs dependencies more quickly than pyenv manages to print its own --help output.
  - mikepurvis 1y ago
    I know there are real reasons for slow Python startup time, with every new import having to examine swaths of filesystem paths to resolve itself, but it really is a noticeable breath of fresh air working with tools implemented in Go or Rust that have sub-ms startup.
    - lxgr 1y ago
      The Python startup latency thing makes sense, but I really don't understand why it would take `pyenv` a long time to print each line of its "usage" output (the one that appears when invoking it with `--help`) once it's already clearly in the code branch that does only that. It feels like like it's doing heavy work between each line printed! I don't know any other cli tool doing that either.
      - heavyset_go 1y ago
        There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.
    - theshrike79 1y ago
Noumenon72 1y ago
If PEP 723 is only an enhancement proposal does it work only because `uv` happens to support it? Can you not use `uvx` with your script because it only works on packages that are installed already or on PyPi?
- wtallis 1y ago
  PEP 723 was incorporated (with modifications) into the official Python packaging specifications: https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata https://packaging.python.org/en/latest/specifications/inline... I don't think running with uv vs uvx imposes any extra limitations on how you specify dependencies. You should either way be able to reference dependencies not just from PyPi but also by git repo or local file path in a [tool.uv.sources] table, the same as you would in a pyproject.toml file.
- deepakjois 1y ago
  uvx is useful to run scripts inside PyPi packages. It does not support running Python scripts directly You can use uvx run scripts with a combination of the --with flag to specify the dependencies and invoking python directly. For e.g uvx --with youtube-transcript-api python transcript.py But you wont get the benefit of PEP 723 metadata.
- rahimnathwani 1y ago
  PEP 723 is final and most relevant tools will support it: https://discuss.python.org/t/40418/82 https://discuss.python.org/t/40418/82
k__ 1y ago
Pretty nice! Some Python devs told me, it's an awesome language, but they envy the Node.js ecosystem for their package management. Seems like uv finally removed that roadblock.
- Y_Y 1y ago
  I think they must have been joking!
  - wavemode 1y ago
    Probably not. NPM has its problems but Python packaging has always been significantly messier (partly because, Python is much older than Node and, indeed, much older than the very concept of resolving dependencies over the internet).
    - int_19h 1y ago
      The upside in Python is that dependencies tend to be more coarse grained and things break less when you update. With JS you have to be on the treadmill constantly to avoid bitrot, and because packages tend to be so small and dependency trees so large, there's a lot of potential points of failure when updating anything.
    - oblio 1y ago
      The bigger problem in Python has been its slowness and reliance on C dependencies. Maven solved Java packaging circa 2005, for example. Yes, XML is verbose, but it's an implementation detail. Python still lags on many fronts, 20 years later. An example: even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). Or why venvs need to be activated with shell-variety specific code.
      - zahlman 1y ago
        > An example: None of this example has anything to do with performance or reliance on C dependencies, but ok. > even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). They aren't designed to be relocatable at all - and that's the only actual stumbling block to it. (They may even contain activation scripts for other platforms!) That's because a bunch of stuff in there specifies absolute paths. In particular, installers (Pip, at least) will generate wrapper scripts that specify absolute paths. This is so that you can copy them out of the environment and have them work. Yes, people really do use that workflow (especially on Windows, where symlinking isn't straightforward). It absolutely could be made to work - probably fairly easily, and there have been calls to sacrifice that workflow to make it work. It's also entirely possible to do a bit of surgery on a relocated venv and make it work again. I've done it a few times. The third-party `virtualenv` also offers some support for this. Their documentation says there are some issues with this. I'm pretty sure they're mainly talking about that wrapper-script-copying use case. > Or why venvs need to be activated with shell-variety specific code. The activation sets environment variables for the current shell. That isn't possible (at least in a cross-platform way) from Python since the Python process would be a child of that shell. (This is also why you have to e.g. use `source` explicitly to run the Linux versions.) But venvs generally don't need to be activated at all. The only things the activation script effectively does: * Set the path environment variable so that the virtual environment's Python (or symlink thereto) will be found first. * Put some fancy stuff in the prompt so that you can feel like you're "in" the virtual environment (a luxury, not at all required). * Set `VIRTUAL_ENV`, which some Python code might care about (but they could equally well check things like `sys.executable`) * Unset (and remember) `PYTHONHOME` (which is a hack that hardly anyone has a good use case for anyway) * (on some systems that don't have a separate explicit deactivate script) set up the means to undo all those changes The actually important thing is the path variable change, and even then you don't need that unless the code is going to e.g. start a Python subprocess and ask the system to find Python. (Or, much more commonly, because you have a `#!/usr/bin/env python` shebang somewhere.) You can just run the virtual environment's Python directly. In particular, you don't have to activate the virtual environment in order to use its wrapper scripts, as long as you can find them. And, in fact, Pipx depends on this.
epistasis 1y ago
This is really great, and it seems that it's becoming more popular. I saw it first on simonw's blog: https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ And there was a March discussion of a different blog post: https://news.ycombinator.com/item?id=43500124 https://news.ycombinator.com/item?id=43500124 I hope this stays on the front page for a while to help publicize it.
- soundblaster 1y ago
  same! nice trick. at the end of article it shows an mcp to fetch youtube subs. I've made a similar one using simonw's llm as a fragment, if you find it useful. llm -f youtube:<id> llm -f yt:<lang>:<id> https://github.com/redraw/llm-fragments-youtube https://github.com/redraw/llm-fragments-youtube
lysace 1y ago
Why do I feel like I’m in an infomercial?
_visgean 1y ago
I honestly don't like that this is expressed as a comment but I guess it makes the implementation easy and backwards compatible...
ACAVJW4H 1y ago
finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended time, space, and the Nix manual. Docker? Great, if downloading a Linux distro to run sed sounds reasonable. There’s got to be a middle ground simple, declarative, and built for humans.
- fouronnes3 1y ago
  Consider porting your shell scripts to Python? The language is vastly superior and subprocess.check_call is not so bad.
- SmellTheGlove 1y ago
  Would homebrew do the job?
  - w0m 1y ago
    Homebrew does a great job @ initial setup; it does a poor job of keeping a system clean and updated over time.
- ndr 1y ago
  Why bother writing new shell scripts? If you're allowed to install any deps go with uv, it'll do the rest. I'm also kinda in love with https://babashka.org/ https://babashka.org/ check it out if you like Clojure.
- bigstrat2003 1y ago
  > Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. IMO it should stay that way, because any script that needs those things is way past the point where shell is a reasonable choice. Shell scripts should be small, 20 lines or so. The language just plain sucks too much to make it worth using for anything bigger.
ravenical 1y ago
https://web.archive.org/web/20250624191820/https://www.cottongeeks.com/articles/2025-06-24-fun-with-uv-and-pep-723 https://web.archive.org/web/20250624191820/https://www.cotto...
- hifikuno 1y ago
  Thanks! I'm guessing it's blocked on your work/uni network too? Stupid over-eager firewall.
  - smcl 1y ago
    I also tried to open it got notified it was blocked due to "pornography" - lovely!
doctoboggan 1y ago
There has been a flurry of `uv` posts on HN recently. I don't have any experience with it, is it really the future, or is it a fad? As Ive gotten older I've grown weary of third party tools, and almost always try to stick with the first party built in methods for a given task. Does uv provide enough benefit to make me reconsider?
- Disposal8433 1y ago
  I'm not a Python master but I've struggled with all the previous package managers, and uv is the first tool that does everything easily (whether it's installing or generating packages or formatting or checking your code). I don't know why there is such a flurry of posts since it's a tool that is more than a year old, but it's the one and only CLI tool that I recommend when Python is needed for local builds or on a CI. Hatch was a good contender at the time but they didn't move fast enough, and the uv/ruff team ate everybody's lunch. uv is really good and IMHO it's here to stay. Anyway try it for yourself but it's not a high-level tool that is hiding everything, it's fast and powerful and yet you stay in control. It feels like a first-party tool that could be included in the Python installer.
- eipipuz 1y ago
  The learning curve is so low that yes. Try it for <20mins and if you don't like it, leave it behind. These 20mins include installation, setup, everything.
- collinmcnulty 1y ago
  I also went through a similar enlightenment of just sticking to pip, but uv convinced me to switch and I’m so glad I did. You can dip your toe in by just using the ‘uv pip’ submodule as a drop in replacement for pip but way faster.
- giantrobot 1y ago
  It is difficult to use Python for utility scripts on the average Linux machine. Deploying Python projects almost require using a container. Popular distros try managing Python packages through the standard package manager rather than pip but not all packages are readily available. Sometimes you're limited by Python version and it can be non-trivial to have multiple versions installed at once. Python packaging has become a shit show. If you use anything outside the standard library the only reliable way to run a script is installing it in a virtual environment. Doing that manually is a hassle and pyenv can be stupidly slow and wastes disk space. With uv it's fast and easy to set up throw away venvs or run utility scripts with their dependencies easily. With the PEP-723 scheme in the linked article running a utility script is even easier since its dependencies are self-declared and a virtual environment is automatically managed. It makes using Python for system scripting/utilities practical and helps deploy larger projects.
sambaumann 1y ago
Between yesterday's thread and this thread I decided to finally give uv a shot today - I'm impressed, both by the speed and how easy it is to manage dependencies for a project. I think their docs could use a little bit of work, especially there should be a defined path to switch from a requirements.txt based workflow to uv. Also I felt like it's a little confusing how to define a python version for a specific project (it's defined in both .python-version and pyproject.toml)
- 0cf8612b2e1e 1y ago
  I have never researched this, but I thought the .python-version file only exists to benefit other tools which may not have a full TOML parser.
  - zahlman 1y ago
    Read-only TOML support is in the standard library since Python 3.11, though. And it's based on an easily obtained third-party package (https://pypi.org/project/tomli/ https://pypi.org/project/tomli/). (If you want to write TOML, or do other advanced things such as preserving comments and exact structure from the original file, you'll want tomlkit instead. Note that it's much less performant.)
    - deleted 1y ago
      [deleted]
- gschizas 1y ago
  > there should be a defined path to switch from a requirements.txt based workflow to uv Try `uvx migrate-to-uv` (see https://pypi.org/project/migrate-to-uv/ https://pypi.org/project/migrate-to-uv/)
- tdhopper 1y ago
  I write an ebook on Python Developer tooling. I've attempted to address some of the weaknesses in the official documentation. How to migrate from requirements.txt: https://pydevtools.com/handbook/how-to/migrate-requirements.txt/ https://pydevtools.com/handbook/how-to/migrate-requirements.... How to change the Python version of a uv project: https://pydevtools.com/handbook/how-to/how-to-change-the-python-version-of-a-uv-project/ https://pydevtools.com/handbook/how-to/how-to-change-the-pyt... Let me know if there are other topics I can hit that would be helpful!
gigatexal 1y ago
Ok I didn’t know about this pep. But I love uv. I use it all day long. Going to use this to change up a lot of my shell scripts into easily runnable Python!
kristianp 1y ago
Does this create a separate environment for each script? If so, won't that create lots of bloat?
- JimDabell 1y ago
  Yes, it creates a separate environment for each script. No, it doesn’t create a lot of bloat. There’s a separate cache and the packages are hard-linked into the environments, so it’s extremely fast and efficient.
  - kristianp 1y ago
    Is the environment located in the .venv folder under the same directory as the script?
    - knowaveragejoe 1y ago
      The venv is created and then discarded once the script finishes execution. This is well suited to one-off scripts like what is demonstrated in the article. In a larger project you can manage venvs like this using `uv venv`, where you end up with a familiar .venv folder.
- zahlman 1y ago
  It does create separate environments. Each environment itself only takes a few dozen kilobytes to make some folders and symlinks (at least on Linux). People think of Python virtual environments as bloated (and slow to create) because Pip gets bootstrapped into them by default. But there is no requirement to do so. The packages take up however much space they take up; the cost there is unavoidable. Uv hard-links packages into the separate environments from its cache, so you only pay a disk-space cost for shared packages once (plus a few more kilobytes for more folders). (Note: none of this depends on being written in Rust, but Pip doesn't implement this caching strategy. Pip can, however, install cross-environment since 22.3, so you don't actually need the bootstrap. Pipx depends on this, managing its own vendored copy of Pip to install into multiple environments. But it's still using a copy of Pip that interacts with a Pip-styled cache, so it still can't do the hard-link trick.)
satvikpendem 1y ago
Very nice, I believe Rust is doing something similar too which is where I initially learned of this idea of single-file shell-type scripts in other languages (with dependency management included, which is how it differs from existing ways of writing single-file scripts in e.g. scripting languages) [0]. Hopefully more languages follow suit on this pattern as it can be extremely useful for many cases, such as passing gists around, writing small programs which might otherwise be written in shell scripts, etc. [0] https://rust-lang.github.io/rfcs/3424-cargo-script.html https://rust-lang.github.io/rfcs/3424-cargo-script.html
- deepakjois 1y ago
  C# too: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
kzrdude 1y ago
I like uv run and uvx like the swiss army knifes of python that they are, but PEP 723 stuff I think is mostly just a gimmick. I'm not convinced it's more than a cool trick.
- zahlman 1y ago
  It's useful for people who don't want to create a "project" or otherwise think about the "ecosystem". People who, if they share their code at all, will email it to coworkers or something. It lets you get by without a pyproject.toml file etc.
- baq 1y ago
  It’s amazing for one-offs.
ali1ism 1y ago
In Ruby, this feature is built-in with its default package manager: [bundler/inline](https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...).
appleaday1 1y ago
been doing this with Pipenv before, but uv is like Pipenv on steroids.
- deleted 1y ago
  [deleted]
js2 1y ago
So far I've only run into one minor ergonomic issue when using `uv run --script` with embedded metadata which is that sometimes I want to test changes to the script via the Python REPL, but that's a bit harder to do since you have to run something like: $ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python >>> from script import X I'd love if there were something more ergonomic like: $ uv run --with-script script.py python Edit: this is better: $ "$(uv python find --script script.py)" >>> from script import X That fires up the correct python and venv for the script. You probably have to run the script once to create it.
- mayli 1y ago
  you are welcome cat ~/.local/bin/uve #!/bin/bash temp=$(mktemp) uv export --script $1 --no-hashes > $temp uv run --with-requirements $temp vim $1 unlink $temp
  - nomel 1y ago
    This is rather silly.
  - jcotton42 1y ago
    If I may ask, why `unlink` instead of `rm`?
- dkdcio 1y ago
  I think you're looking for something like this (the important part being embeddeding a REPL call toward the end after whateve rsetup): https://gist.github.com/lostmygithubaccount/77d12d03894953bc98960c1878869028 https://gist.github.com/lostmygithubaccount/77d12d03894953bc... You can make `--interactive` or whatever you want a CLI flag from the script. I often make these small Typer CLIs with something like that (or in this case, in another dev script like this, I have `--sql` for entering a DuckDB SQL repl)
tpoacher 1y ago
> If you are not a Pythonista (or one possibly living under a rock) That's bait! / Ads are getting smarter! I would also have accepted "unless you're geh", "unless you're a traitor to the republic", "unless you're not leet enough" etc.
- SpaceNugget 1y ago
  I'm not a python dev, but if you read HN even semi-regularly you have surely come across it several times in at least the past few months if not a year by now. It is all the rage these days in python world it seems. And so, if you are the kind of person who has not heard of it, you probably don't read blogs about python, therefor you probably aren't reading _this_ blog. No harm no foul.
tpoacher 1y ago
What's going on? This whole thread reads like paid amazon reviews
- indosauros 1y ago
  What's going on is "we have 14 standards so we need to create a 15th" actually worked this time
  - kibwen 1y ago
    It works far more of the time than people give it credit for. There are a lot of good XKCDs, but that one is by far the worst one ever made, as far as being a damaging meme goes.
    - mturmon 1y ago
      "xkcd 927 Considered Harmful" ?
      - nickagliano 1y ago
        Fantastic comment
    - hnfong 1y ago
      It's survival bias. You'd never see the confusion from would-have-failed standards-wannabes that xkcd927 helped prevent.
  - mmcnl 1y ago
    To be fair, I've used Poetry for years and it works/worked amazingly well. It's just not as fast as uv.
- deleted 1y ago
  [deleted]
- oblio 1y ago
  Occasionally the reviews match reality.
AstroJetson 1y ago
> uv is an extremely fast Python package and project manager, written in Rust. Is there a version of uv written in Python? It's weird (to me) to have an entire ecosystem for a language and a highly recommended tool to make your system work is written in another language.
- ebb_earl_co 1y ago
  Well, I use Debian and Bash: pretty much everything to make my system work, including and especially Python development, is written in C, another language!
- dralley 1y ago
  pip? A tool written in Python is never going to be as fast as one written in Rust. There are plenty of Python alternatives and you're free to use them.
- sgeisenh 1y ago
  Similar to ruff, uv mostly gathers ideas from other tools (with strong opinions and a handful of thoughtful additions and adjustments) and implements them in Rust for speed improvements. Interestingly, the speed is the main differentiator from existing package and project management tools. Even if you are using it as a drop-in replacement for pip, it is just so much faster.
- zahlman 1y ago
  They are not making a Python version. There are many competing tools in the space, depending on how you define the project requirements. Contrary to the implication of other replies, the lion's share of uv's speed advantage over Pip does not come from being written in Rust, from any of the evidence available to me. It comes from: * bootstrapping Pip into the new environment, if you make a new environment and don't know that you don't actually have to bootstrap Pip into that environment (see https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... for some hints; my upcoming post will be more direct about it - unfortunately I've been putting it off...) * being designed up front to install cross-environment (if you want to do this with Pip, you'll eventually and with much frustration get a subtly broken installation using the old techniques; since 22.3 you can just use the `--python` flag, but this limits you to environments where the current Pip can run, and re-launches a new Pip process taking perhaps an additional 200ms - but this is still much better than bootstrapping another copy of Pip!) * using heuristics when solving for dependencies (Pip's backtracking resolver is exhaustive, and proceeds quite stubbornly in order) * having a smarter caching strategy (it stores uncompressed wheels in its cache and does most of the "installation" by hard-linking these into the new environment; Pip goes through a proxy that uses some opaque cache files to simulate re-doing the download, then unpacks the wheel again) * not speculatively pre-loading a bunch of its own code that's unlikely to execute (Pip has large complex dependencies, like https://pypi.org/project/rich/ https://pypi.org/project/rich/, which it vendors without tree-shaking and ultimately imports almost all of, despite using only a tiny portion) * having faster default behaviours; e.g. uv defaults to not pre-compiling installed packages to .pyc files (since Python will do this on the first import anyway) while Pip defaults to doing so * not (necessarily) being weighed down by support for legacy behaviours (packaging worked radically differently when Pip first became publicly available) * just generally being better architected None of these changes require a change in programming language. (For example, if you use Python to make a hard link, you just use the standard library, which will then use code written in C to make a system call that was most likely also written in C.) Which is why I'm making https://github.com/zahlman/paper https://github.com/zahlman/paper .
quibono 1y ago
Last time I looked at switching from poetry to uv I had an issue with pinning certain dependencies to always install from a private PyPI repository. Is there a way to do that now? (also: possible there's always been a way and I'm an idiot)
- codethief 1y ago
  You mean something like https://docs.astral.sh/uv/concepts/indexes/ https://docs.astral.sh/uv/concepts/indexes/ ?
- jplumail 1y ago
  Yes, see: https://docs.astral.sh/uv/concepts/projects/dependencies/#index https://docs.astral.sh/uv/concepts/projects/dependencies/#in...
tyrion 1y ago
Some years ago I thought it would be interesting to develop a tool to make a python script automatically install its own dependencies (like uvx in the article), but without requiring any other external tool, except python itself, to be installed. The downside is that there are a bunch of seemingly weird lines you have to paste at the begging of the script :D If anyone is curios it's on pypi (pysolate).
- dkdcio 1y ago
  Also this thing that never took off: https://github.com/fal-ai/isolate https://github.com/fal-ai/isolate Not quite the same but interesting!
puika 1y ago
Like the author, I find myself going more for cross-platform Python one-offs and personal scripts for both work and home and ditching Go. I just wish Python typechecking weren't the shitshow it is. Looking forward to ty, pyrefly, etc. to improve the situation a bit
- SavioMak 1y ago
  Speed is one thing, the type system itself is another thing, you are basically guaranteed to hit like 5-10 issues with python's weird type system before you start grasping some of the oddities
- ViscountPenguin 1y ago
  I've never particularly liked go for cross platform code anyway. I've always found it pretty tightly wedded to Unix. Python has its fair share of issues on windows aswell though, I've been stuck debugging weird .DLL issues with libraries for far too long in my life. Strangely, I've found myself building personal cross platform apps in game engines because of that.
- silverwind 1y ago
  I do hope the community will converge on one type checker like ty. The fact that multiple type checkers exist is really hindering to the language as a whole.
- davidatbu 1y ago
  I wouldn't describe Python type checking as a shit-show. pyright is pretty much perfect. One nit against it perhaps is that it doesn't support non-standard typing constructs like mypy does (for Django etc). That's an intentional decision on the maintainer's part. And I'm glad he made that decision because that spurned efforts to make the standard typing constructs more expressive. I'm also looking forward to the maturity of Rust-based type checkers, but solely because one can almost always benefit from an order of magnitude improvement in speed of type checking, not because Python type-checking is a "shit show". I do grant you that for outsiders, the fact that the type checker from the Python organization itself is actually a second rate type checker (except for when one uses Django, etc, and then it becomes first-rate) is confusing.
divbzero 1y ago
If momentum for uv in the community continues, I’d love to see it distributed more broadly. uv can already be installed easily on macOS via Homebrew (like pyenv). uv can also be installed on Windows via WinGet (unlike pyenv). It would be nice to see it packaged for Linux as well.
- mixmastamyk 1y ago
  $ dnf search --cacheonly uv Matched fields: name (exact) uv.x86_64: An extremely fast Python package installer and resolver, written in Rust
mont_tag 1y ago
Grace Hopper technology: A well formed Python program shall define an ENVIRONMENT division that specifies the environment in which the program will be compiled and executed. It outlines the hardware and software dependencies. This division is crucial for making COBOL^H^H^H^H^HPython programs portable across different systems.
bjourne 1y ago
> For the longest time, I have been frustrated with Python because I couldn’t use it for one-off scripts. Bruh, one-off scripts is the whole point of Python. The cheat code is to add "break-system-packages = true" to ~/.config/pip/pip.conf. Just blow up ~/.local/lib/pythonX.Y/site-packages/ if you run into a package conflict (exceedingly rare) and reinstall. All these venv, uv, metadata peps, and whatnot are pointless complications you just don't need.
kristianp 1y ago
If you want to manually manage envs and you're using conda, you can activate the env in a shell wrapper for your python script, like so (this is with conda) #!/usr/bin/env bash eval "$(conda shell.bash hook)" conda activate myenv python myscript Admittedly this isn't self contained like the PEP 723 solution.
divbzero 1y ago
This is very cool. Note that PEP 723 is also supported by pipx run: https://pipx.pypa.io/latest/examples/#pipx-run-examples https://pipx.pypa.io/latest/examples/#pipx-run-examples
gerdesj 1y ago
I've recently updated a Python script that I originally wrote about 10 years ago. I'm not a programmer - I just have to get stuff done - think sysops. For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept. When Python first came out, our processors were 80486 at best and RAM was measured in MB at roughly £30/MB in the UK. "For the longest time, ..." - all distros have had scripts that find the relevant Python or Java or whatevs so that's simply daft. They all have shebang incantations too. So we now have uv written in Rust for Python. Obviously you should install it via a shell script directly from curl! I love all of the components involved here but please for the love of a nod to security at least suggest that the script is downloaded first, looked over and then run. I recently came across a Github hosted repo with scripts that changed Debian repos to point somewhere else and install ... software. I'm sure that's all fine too. curl | bash is cute and easy and very, very insecure.
- wiseowise 1y ago
  > Obviously you should install it via a shell script directly from curl! No? You can install it via pip.
  - benrutter 1y ago
    You can do both but the official recomendation is shell + curl[0]. Not an expert but I think there's performance gains to calling the binary directly rather than through python. [0]: https://docs.astral.sh/uv/ https://docs.astral.sh/uv/
  - gerdesj 1y ago
    I was going off on a bit of a tangent but take a look at this horror, which is still up: https://github.com/InboraStudio/Proxmox-VGPU https://github.com/InboraStudio/Proxmox-VGPU Note the quite professional looking README.md and think about the audience for this thing - kittens hitting the search bong and trying to get something very complicated working. Read the scripts: they are pretty short and could put your hypervisor in the hands of someone else who may not be too friendly. Now pip has the same problem except you don't normally go in with a web browser first. I raised an issue to at least provide a hint to casual browsers and also raised it with the github AI bottie complaint thang which doesn't care about you, me or anything else for that matter.
4dregress 1y ago
I’ve been a python dev for nearly a decade and never once thought dep management was a problem. If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell . So I still don’t see what the fuss is about? I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI setup times.
- petersellers 1y ago
  > it’s always been done in that ENVs python shell . What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.
  - kinow 1y ago
    I wrote PHP/JS/Java before Python. Been doing Python for nearly a decade too, and like 4dregress haven't had the need to worry much about dep management. JS and PHP had all sorts of issues, Maven & Gradle are still the ones that gave me less trouble. With Python I found that most issues could be fixed by finding the PEP that implemented what I needed, and by trying to come up with a simple workflow & packaging strategy. Nowadays I normally use `python venv/bin/<some-executable>`, or `conda run -n <some-env> <some-executable>`, or packaged it in a Singularity container. And even though I hear a lot of good things about uv, given that my job uses public money for research, we try to use open source and standards as much as possible. My understanding is that uv is still backed by a company, and at least when I checked it some time ago (in peps discussions & GH issues) they were no implementing the PEPs that I needed -- even if they did, we would probably still stay with simple pip/setuptools to avoid having to use research budget to update our build if the company ever changed its business model (e.g. what anaconda did some months/year? ago). Digressing: the Singularity container is useful for research & HPC too, as it creates a single archive, which is faster to load on distributed filesystems like the two I work on (GPFS & LustreFS) instead of loading many small files over network.
  - arcanemachiner 1y ago
rednafi 1y ago
> Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable. I still do because: - Go gives me a single binary - Dependencies are statically linked - I don’t need any third-party libs in most scenarios - Many of my scripts make network calls, and Go has a better stdlib for HTTP/RPC/Socket work - Better tooling (built-in formatter, no need for pytest, go vet is handy) - Easy concurrency. Most of my scripts don’t need it, but when they do, it’s easier since I don’t have to fiddle with colored functions, external libs, or, worse, threads. That said, uv is a great improvement over the previous status quo. But I don’t write Python scripts for reasons that go beyond just tooling. And since it’s not a standard tool, I worry that more things like this will come along and try to “improve” everything. Already scarred and tired in that area thanks to the JS ecosystem. So I tend to prefer stable, reliable, and boring tools over everything else. Right now, Go does that well enough for my scripting needs.
- 7bit 1y ago
  Good for you. I dont See how this is relevant to this topic.
  - rednafi 1y ago
    > Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable. Here's how it's relevant :)
- deepakjois 1y ago
  (author of post here) I still use both Go and Python. But Python gives me access to a lot more libraries that do useful stuff. For example the YouTube transcript example I wrote about in the article was only possible in Python because afaik Go doesn't have a decent library for transcript extraction.
  - rednafi 1y ago
    Yeah that's a fair point. I still do a ton of Python for work. The language is fine; it's mostly tooling that still feels 30 years old.
zidoo 1y ago
My only question is: who asked for faster pip?
- 0x008 1y ago
  Comparing apples and orange here. Uv scope is so much more than pip
- TypingOutBugs 1y ago
  uv has a lot more perks! It makes distributing python tooling easier too
syhol 1y ago
Mise has a very similar feature with its shebangs: https://mise.jdx.dev/tips-and-tricks.html#shebang https://mise.jdx.dev/tips-and-tricks.html#shebang #!/usr/bin/env -S mise x xh jq fzf gum -- bash todo=$(xh 'https://jsonplaceholder.typicode.com/todos' | jq '.[].title' | fzf) gum style --border double --padding 1 "$todo" It makes throwing together a bash scripts with dependencies very enjoyable
zelphirkalt 1y ago
Using Guix (guix shell) it was already possible to run Python scripts one-off. I see others have also commented about doing it using Nix. Also that would be reproducible, in contrast to what is shown in the blog post. To make that reproducible, one would have to keep the lock file somewhere, or state the checksums directly in the Python script file, which seems rather un-fun.
Imustaskforhelp 1y ago
I have a lot of opinions about this. Firstly, I have been a HN viewer for so many time and this is the one thing about pep python scripts THAT always get to the top of leaderboard of hackernews by each person discovering it themselves. I don't mean to discredit the author. His work was simple and clear to understand. I am just sharing this thesis that I have that if someone wants karma on Hackernews for whatever reason, this might be the best topic. (Please don't pitchfork me since I don't mean offense to the author) Also, can anybody please explain to me on how to create that pep metadata in uv from just a python script and without anything else, like some command which can take a python script and give pep and add that in the script, I am pretty sure that uv has a feature flag but I feel that the author might've missed out on this feature because I don't know when coding one off scripts in python using AI (gemini) it had some options with pep so I always had to paste uv's documentation I don't know, so please if anybody knows a way to create pep easier using the cli, then please tell me! Thanks in advance!!
- altbdoor 1y ago
  One can use uv to add into the dependencies list $ touch foo.py $ uv add --script foo.py requests Updated `foo.py` $ cat foo.py # /// script # requires-python = ">=3.13" # dependencies = [ # "requests", # ] # ///
  - Imustaskforhelp 1y ago
    Thanks a lot friend, But one of the issues with this is that I need to know about requests and sometimes their names can be different and I actually had created a cli tool called uvman which actually wanted to automate that part too. But my tool was really finnicky and I guess it was built by AI ,so um yea, I guess you all can try it, its on pypi. I think that it has a lot of niche cases where it doesn't work. Maybe someone can modify it to make it better as I had built it like 3-4 months ago if I remember correctly and I have completely forgotten how things worked in uv.
pseudosavant 1y ago
Between how good ChatGPT/Claude are at writing Python, and discovering uv + PEP 723, I'm creating all sorts of single file python scripts. Some of my recent personal tools: compression stats for resources when gzipped, minify SVGs, a duplicate file tool, a ping testing tool, a tool for processing large CSVs through LLMs one row at a time, etc. uv is the magic that deals with all of the rough edges/environment stuff I usually hate in Python. All I need to do is `uv run myFile.py` and uv solves everything else.
jasonm23 1y ago
This seems timely, `uv` is a complete revelation for me and has made working with Python extremely convenient ... the Python "just works" time has arrived. I'm building yt-dlp / uvx based WebUI - https://github.com/ocodo/uvxytdlp https://github.com/ocodo/uvxytdlp Still work in progress but shaping up nicely.
timkofu 1y ago
Nice.

640 points by deepakjois 1y ago

There's no lockfile or anything with this approach right? So in a year or two all of these scripts will be broken because people didn't pin their dependencies? I like it though. It's very convenient.

rahimnathwani 1y ago
PEP 723 allows you to specify version numbers for direct dependencies, but of course indirect dependencies aren't guaranteed to be the same.
js2 1y ago
> There's no lockfile or anything with this approach right? There are options to both lock the dependencies and limit by date: https://docs.astral.sh/uv/guides/scripts/#locking-dependencies https://docs.astral.sh/uv/guides/scripts/#locking-dependenci... https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...
zahlman 1y ago
> So in a year or two all of these scripts will be broken because people didn't pin their dependencies? People act like this happens all the time but in practice I haven't seen evidence that it's a serious problem. The Python ecosystem is not the JavaScript ecosystem.
- nomel 1y ago
  I think it's because you don't maintain much python code, or use many third party libraries. An easy way to prove that this is the norm is to take some existing code you have now, and update to the latest versions your dependencies are using, and watch everything break. You don't see a problem because those dependencies are using pinned/very restricted versions, to hide the frequency of the problem from you. You'll also see that, in their issue trackers, they've closed all sorts of version related bugs.
  - zahlman 1y ago
    > An easy way to prove that this is the norm is to take some existing code you have now, and update to the latest versions your dependencies are using I have done this many times and watched everything fail to break.
    - nomel 1y ago
      Are you sure you’re reading what I wrote fully? Getting pip, or any of them, to ignore all version requirements, including those listed by the dependencies themselves, required modifying source, last I tried. I’ve had to modify code this week due to changes in some popular libraries. Some recent examples are Numpy 2.0 broke most code that used numpy. They changed the c side (full interpreter crashes with trimesh) and removed/moved common functions, like array.ptp(). Scipy moved a bunch of stuff lately, and fully removed some image related things. If you think python libraries are somehow stable in time, you just don’t use many.
      - zahlman 1y ago
        ... So if the installer isn't going to ignore the version requirements, and thereby install an unsupported package that causes a breakage, then there isn't a problem with "scripts being broken because people didn't pin their dependencies". The packages listed in the PEP 723 metadata get installed by an installer, which resolves the listed (unpinned) dependencies to concrete ones (including transitive dependencies), following rules specified by the packages. I thought we were talking about situations in which following those rules still leads to a runtime fault. Which is certainly possible, but in my experience a highly overstated risk. Packages that say they will work with `foolib >= 3` will very often continue to work with foolib 4.0, and the risk that they don't is commonly-in-the-Python-world considered worth it to avoid other problems caused by specifying `foolib >=3, <4` (as described in e.g. https://iscinumpy.dev/post/bound-version-constraints/ https://iscinumpy.dev/post/bound-version-constraints/ ). The real problem is that there isn't a good way (from the perspective of the intermediate dependency's maintainer) to update the metadata after you find out that a new version of a (further-on) dependency is incompatible. You can really only upload a new patch version (or one with a post-release segment in the version number) and hope that people haven't pinned their dependencies so strictly as to exclude the fix. (Although they shouldn't be doing that unless they also pin transitive dependencies!) That said, the end user can add constraints to Pip's dependency resolution by just creating a constraints file and specifying it on the command line. (This was suggested as a workaround when Setuptools caused a bunch of legacy dependencies to explode - not really the same situation, though, because that's a build-time dependency for some packages that were only made available as sdists, even pure-Python ones. Ideally everyone would follow modern practice as described at https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-python/ https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-... , but sometimes the maintainers are entirely MIA.) > Numpy 2.0 is a very recent example that broke most code that used numpy. This is fair to note, although I haven't seen anything like a source that would objectively establish the "most" part. The ABI changes in particular are only relevant for packages that were building their own C or Fortran code against Numpy.

jkingsman 1y ago

uv has been fantastic to use for little side projects. Combining uv run with `uv tool run` AKA `uvx` means one can fetch, install within a VM, and execute Python scripts from Github super easily. No git clone, no venv creation + entry + pip install. And uv is fast — I mean REALLY fast. Fast to the point of suspecting something went wrong and silently errored, when it fact it did just what I wanted but 10x faster than pip. It (and especially its docs) are a little rough around the edges, but it's bold enough and good enough I'm willing to use it nonetheless.

lxgr 1y ago
Truly. uv somehow resolves and installs dependencies more quickly than pyenv manages to print its own --help output.
- mikepurvis 1y ago
  I know there are real reasons for slow Python startup time, with every new import having to examine swaths of filesystem paths to resolve itself, but it really is a noticeable breath of fresh air working with tools implemented in Go or Rust that have sub-ms startup.
  - lxgr 1y ago
    The Python startup latency thing makes sense, but I really don't understand why it would take `pyenv` a long time to print each line of its "usage" output (the one that appears when invoking it with `--help`) once it's already clearly in the code branch that does only that. It feels like like it's doing heavy work between each line printed! I don't know any other cli tool doing that either.
    - heavyset_go 1y ago
      There's a launcher wrapper shell script + Python startup time that contributes to pyenv's slow launch times.
  - theshrike79 1y ago

Noumenon72 1y ago

If PEP 723 is only an enhancement proposal does it work only because `uv` happens to support it? Can you not use `uvx` with your script because it only works on packages that are installed already or on PyPi?

wtallis 1y ago
PEP 723 was incorporated (with modifications) into the official Python packaging specifications: https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata https://packaging.python.org/en/latest/specifications/inline... I don't think running with uv vs uvx imposes any extra limitations on how you specify dependencies. You should either way be able to reference dependencies not just from PyPi but also by git repo or local file path in a [tool.uv.sources] table, the same as you would in a pyproject.toml file.
deepakjois 1y ago
uvx is useful to run scripts inside PyPi packages. It does not support running Python scripts directly You can use uvx run scripts with a combination of the --with flag to specify the dependencies and invoking python directly. For e.g uvx --with youtube-transcript-api python transcript.py But you wont get the benefit of PEP 723 metadata.
rahimnathwani 1y ago
PEP 723 is final and most relevant tools will support it: https://discuss.python.org/t/40418/82 https://discuss.python.org/t/40418/82

k__ 1y ago

Pretty nice! Some Python devs told me, it's an awesome language, but they envy the Node.js ecosystem for their package management. Seems like uv finally removed that roadblock.

Y_Y 1y ago
I think they must have been joking!
- wavemode 1y ago
  Probably not. NPM has its problems but Python packaging has always been significantly messier (partly because, Python is much older than Node and, indeed, much older than the very concept of resolving dependencies over the internet).
  - int_19h 1y ago
    The upside in Python is that dependencies tend to be more coarse grained and things break less when you update. With JS you have to be on the treadmill constantly to avoid bitrot, and because packages tend to be so small and dependency trees so large, there's a lot of potential points of failure when updating anything.
  - oblio 1y ago
    The bigger problem in Python has been its slowness and reliance on C dependencies. Maven solved Java packaging circa 2005, for example. Yes, XML is verbose, but it's an implementation detail. Python still lags on many fronts, 20 years later. An example: even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). Or why venvs need to be activated with shell-variety specific code.
    - zahlman 1y ago
      > An example: None of this example has anything to do with performance or reliance on C dependencies, but ok. > even now it makes 0 sense to me why virtual envs are not designed and supposed to be portable between machines with the same architecture (!). They aren't designed to be relocatable at all - and that's the only actual stumbling block to it. (They may even contain activation scripts for other platforms!) That's because a bunch of stuff in there specifies absolute paths. In particular, installers (Pip, at least) will generate wrapper scripts that specify absolute paths. This is so that you can copy them out of the environment and have them work. Yes, people really do use that workflow (especially on Windows, where symlinking isn't straightforward). It absolutely could be made to work - probably fairly easily, and there have been calls to sacrifice that workflow to make it work. It's also entirely possible to do a bit of surgery on a relocated venv and make it work again. I've done it a few times. The third-party `virtualenv` also offers some support for this. Their documentation says there are some issues with this. I'm pretty sure they're mainly talking about that wrapper-script-copying use case. > Or why venvs need to be activated with shell-variety specific code. The activation sets environment variables for the current shell. That isn't possible (at least in a cross-platform way) from Python since the Python process would be a child of that shell. (This is also why you have to e.g. use `source` explicitly to run the Linux versions.) But venvs generally don't need to be activated at all. The only things the activation script effectively does: * Set the path environment variable so that the virtual environment's Python (or symlink thereto) will be found first. * Put some fancy stuff in the prompt so that you can feel like you're "in" the virtual environment (a luxury, not at all required). * Set `VIRTUAL_ENV`, which some Python code might care about (but they could equally well check things like `sys.executable`) * Unset (and remember) `PYTHONHOME` (which is a hack that hardly anyone has a good use case for anyway) * (on some systems that don't have a separate explicit deactivate script) set up the means to undo all those changes The actually important thing is the path variable change, and even then you don't need that unless the code is going to e.g. start a Python subprocess and ask the system to find Python. (Or, much more commonly, because you have a `#!/usr/bin/env python` shebang somewhere.) You can just run the virtual environment's Python directly. In particular, you don't have to activate the virtual environment in order to use its wrapper scripts, as long as you can find them. And, in fact, Pipx depends on this.

epistasis 1y ago

This is really great, and it seems that it's becoming more popular. I saw it first on simonw's blog: https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ https://simonwillison.net/2024/Dec/19/one-shot-python-tools/ And there was a March discussion of a different blog post: https://news.ycombinator.com/item?id=43500124 https://news.ycombinator.com/item?id=43500124 I hope this stays on the front page for a while to help publicize it.

soundblaster 1y ago
same! nice trick. at the end of article it shows an mcp to fetch youtube subs. I've made a similar one using simonw's llm as a fragment, if you find it useful. llm -f youtube:<id> llm -f yt:<lang>:<id> https://github.com/redraw/llm-fragments-youtube https://github.com/redraw/llm-fragments-youtube

lysace 1y ago

Why do I feel like I’m in an infomercial?

_visgean 1y ago

I honestly don't like that this is expressed as a comment but I guess it makes the implementation easy and backwards compatible...

ACAVJW4H 1y ago

finally feels like Python scripts can Just Work™ without a virtualenv scavenger hunt. Now if only someone could do the same for shell scripts. Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. Right now it’s still curl | bash and hope for the best, or a README with 12 manual steps and three missing dependencies. Sure, there’s Nix... if you’ve already transcended time, space, and the Nix manual. Docker? Great, if downloading a Linux distro to run sed sounds reasonable. There’s got to be a middle ground simple, declarative, and built for humans.

fouronnes3 1y ago
Consider porting your shell scripts to Python? The language is vastly superior and subprocess.check_call is not so bad.
SmellTheGlove 1y ago
Would homebrew do the job?
- w0m 1y ago
  Homebrew does a great job @ initial setup; it does a poor job of keeping a system clean and updated over time.
ndr 1y ago
Why bother writing new shell scripts? If you're allowed to install any deps go with uv, it'll do the rest. I'm also kinda in love with https://babashka.org/ https://babashka.org/ check it out if you like Clojure.
bigstrat2003 1y ago
> Packaging, dependency management, and reproducibility in shell land are still stuck in the Stone Ages. IMO it should stay that way, because any script that needs those things is way past the point where shell is a reasonable choice. Shell scripts should be small, 20 lines or so. The language just plain sucks too much to make it worth using for anything bigger.

ravenical 1y ago

https://web.archive.org/web/20250624191820/https://www.cottongeeks.com/articles/2025-06-24-fun-with-uv-and-pep-723 https://web.archive.org/web/20250624191820/https://www.cotto...

hifikuno 1y ago
Thanks! I'm guessing it's blocked on your work/uni network too? Stupid over-eager firewall.
- smcl 1y ago
  I also tried to open it got notified it was blocked due to "pornography" - lovely!

doctoboggan 1y ago

There has been a flurry of `uv` posts on HN recently. I don't have any experience with it, is it really the future, or is it a fad? As Ive gotten older I've grown weary of third party tools, and almost always try to stick with the first party built in methods for a given task. Does uv provide enough benefit to make me reconsider?

Disposal8433 1y ago
I'm not a Python master but I've struggled with all the previous package managers, and uv is the first tool that does everything easily (whether it's installing or generating packages or formatting or checking your code). I don't know why there is such a flurry of posts since it's a tool that is more than a year old, but it's the one and only CLI tool that I recommend when Python is needed for local builds or on a CI. Hatch was a good contender at the time but they didn't move fast enough, and the uv/ruff team ate everybody's lunch. uv is really good and IMHO it's here to stay. Anyway try it for yourself but it's not a high-level tool that is hiding everything, it's fast and powerful and yet you stay in control. It feels like a first-party tool that could be included in the Python installer.
eipipuz 1y ago
The learning curve is so low that yes. Try it for <20mins and if you don't like it, leave it behind. These 20mins include installation, setup, everything.
collinmcnulty 1y ago
I also went through a similar enlightenment of just sticking to pip, but uv convinced me to switch and I’m so glad I did. You can dip your toe in by just using the ‘uv pip’ submodule as a drop in replacement for pip but way faster.
giantrobot 1y ago
It is difficult to use Python for utility scripts on the average Linux machine. Deploying Python projects almost require using a container. Popular distros try managing Python packages through the standard package manager rather than pip but not all packages are readily available. Sometimes you're limited by Python version and it can be non-trivial to have multiple versions installed at once. Python packaging has become a shit show. If you use anything outside the standard library the only reliable way to run a script is installing it in a virtual environment. Doing that manually is a hassle and pyenv can be stupidly slow and wastes disk space. With uv it's fast and easy to set up throw away venvs or run utility scripts with their dependencies easily. With the PEP-723 scheme in the linked article running a utility script is even easier since its dependencies are self-declared and a virtual environment is automatically managed. It makes using Python for system scripting/utilities practical and helps deploy larger projects.

sambaumann 1y ago

Between yesterday's thread and this thread I decided to finally give uv a shot today - I'm impressed, both by the speed and how easy it is to manage dependencies for a project. I think their docs could use a little bit of work, especially there should be a defined path to switch from a requirements.txt based workflow to uv. Also I felt like it's a little confusing how to define a python version for a specific project (it's defined in both .python-version and pyproject.toml)

0cf8612b2e1e 1y ago
I have never researched this, but I thought the .python-version file only exists to benefit other tools which may not have a full TOML parser.
- zahlman 1y ago
  Read-only TOML support is in the standard library since Python 3.11, though. And it's based on an easily obtained third-party package (https://pypi.org/project/tomli/ https://pypi.org/project/tomli/). (If you want to write TOML, or do other advanced things such as preserving comments and exact structure from the original file, you'll want tomlkit instead. Note that it's much less performant.)
  - deleted 1y ago
    [deleted]
gschizas 1y ago
> there should be a defined path to switch from a requirements.txt based workflow to uv Try `uvx migrate-to-uv` (see https://pypi.org/project/migrate-to-uv/ https://pypi.org/project/migrate-to-uv/)
tdhopper 1y ago
I write an ebook on Python Developer tooling. I've attempted to address some of the weaknesses in the official documentation. How to migrate from requirements.txt: https://pydevtools.com/handbook/how-to/migrate-requirements.txt/ https://pydevtools.com/handbook/how-to/migrate-requirements.... How to change the Python version of a uv project: https://pydevtools.com/handbook/how-to/how-to-change-the-python-version-of-a-uv-project/ https://pydevtools.com/handbook/how-to/how-to-change-the-pyt... Let me know if there are other topics I can hit that would be helpful!

gigatexal 1y ago

Ok I didn’t know about this pep. But I love uv. I use it all day long. Going to use this to change up a lot of my shell scripts into easily runnable Python!

kristianp 1y ago

Does this create a separate environment for each script? If so, won't that create lots of bloat?

JimDabell 1y ago
Yes, it creates a separate environment for each script. No, it doesn’t create a lot of bloat. There’s a separate cache and the packages are hard-linked into the environments, so it’s extremely fast and efficient.
- kristianp 1y ago
  Is the environment located in the .venv folder under the same directory as the script?
  - knowaveragejoe 1y ago
    The venv is created and then discarded once the script finishes execution. This is well suited to one-off scripts like what is demonstrated in the article. In a larger project you can manage venvs like this using `uv venv`, where you end up with a familiar .venv folder.
zahlman 1y ago
It does create separate environments. Each environment itself only takes a few dozen kilobytes to make some folders and symlinks (at least on Linux). People think of Python virtual environments as bloated (and slow to create) because Pip gets bootstrapped into them by default. But there is no requirement to do so. The packages take up however much space they take up; the cost there is unavoidable. Uv hard-links packages into the separate environments from its cache, so you only pay a disk-space cost for shared packages once (plus a few more kilobytes for more folders). (Note: none of this depends on being written in Rust, but Pip doesn't implement this caching strategy. Pip can, however, install cross-environment since 22.3, so you don't actually need the bootstrap. Pipx depends on this, managing its own vendored copy of Pip to install into multiple environments. But it's still using a copy of Pip that interacts with a Pip-styled cache, so it still can't do the hard-link trick.)

satvikpendem 1y ago

Very nice, I believe Rust is doing something similar too which is where I initially learned of this idea of single-file shell-type scripts in other languages (with dependency management included, which is how it differs from existing ways of writing single-file scripts in e.g. scripting languages) [0]. Hopefully more languages follow suit on this pattern as it can be extremely useful for many cases, such as passing gists around, writing small programs which might otherwise be written in shell scripts, etc. [0] https://rust-lang.github.io/rfcs/3424-cargo-script.html https://rust-lang.github.io/rfcs/3424-cargo-script.html

deepakjois 1y ago
C# too: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/ https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...

kzrdude 1y ago

I like uv run and uvx like the swiss army knifes of python that they are, but PEP 723 stuff I think is mostly just a gimmick. I'm not convinced it's more than a cool trick.

zahlman 1y ago
It's useful for people who don't want to create a "project" or otherwise think about the "ecosystem". People who, if they share their code at all, will email it to coworkers or something. It lets you get by without a pyproject.toml file etc.
baq 1y ago
It’s amazing for one-offs.

ali1ism 1y ago

In Ruby, this feature is built-in with its default package manager: [bundler/inline](https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...).

appleaday1 1y ago

been doing this with Pipenv before, but uv is like Pipenv on steroids.

deleted 1y ago
[deleted]

js2 1y ago

So far I've only run into one minor ergonomic issue when using `uv run --script` with embedded metadata which is that sometimes I want to test changes to the script via the Python REPL, but that's a bit harder to do since you have to run something like: $ uv run --python=3.13 --with-requirements <(uv export --script script.py) -- python >>> from script import X I'd love if there were something more ergonomic like: $ uv run --with-script script.py python Edit: this is better: $ "$(uv python find --script script.py)" >>> from script import X That fires up the correct python and venv for the script. You probably have to run the script once to create it.

mayli 1y ago
you are welcome cat ~/.local/bin/uve #!/bin/bash temp=$(mktemp) uv export --script $1 --no-hashes > $temp uv run --with-requirements $temp vim $1 unlink $temp
- nomel 1y ago
  This is rather silly.
- jcotton42 1y ago
  If I may ask, why `unlink` instead of `rm`?
dkdcio 1y ago
I think you're looking for something like this (the important part being embeddeding a REPL call toward the end after whateve rsetup): https://gist.github.com/lostmygithubaccount/77d12d03894953bc98960c1878869028 https://gist.github.com/lostmygithubaccount/77d12d03894953bc... You can make `--interactive` or whatever you want a CLI flag from the script. I often make these small Typer CLIs with something like that (or in this case, in another dev script like this, I have `--sql` for entering a DuckDB SQL repl)

tpoacher 1y ago

> If you are not a Pythonista (or one possibly living under a rock) That's bait! / Ads are getting smarter! I would also have accepted "unless you're geh", "unless you're a traitor to the republic", "unless you're not leet enough" etc.

SpaceNugget 1y ago
I'm not a python dev, but if you read HN even semi-regularly you have surely come across it several times in at least the past few months if not a year by now. It is all the rage these days in python world it seems. And so, if you are the kind of person who has not heard of it, you probably don't read blogs about python, therefor you probably aren't reading _this_ blog. No harm no foul.

tpoacher 1y ago

What's going on? This whole thread reads like paid amazon reviews

indosauros 1y ago
What's going on is "we have 14 standards so we need to create a 15th" actually worked this time
- kibwen 1y ago
  It works far more of the time than people give it credit for. There are a lot of good XKCDs, but that one is by far the worst one ever made, as far as being a damaging meme goes.
  - mturmon 1y ago
    "xkcd 927 Considered Harmful" ?
    - nickagliano 1y ago
      Fantastic comment
  - hnfong 1y ago
    It's survival bias. You'd never see the confusion from would-have-failed standards-wannabes that xkcd927 helped prevent.
- mmcnl 1y ago
  To be fair, I've used Poetry for years and it works/worked amazingly well. It's just not as fast as uv.
deleted 1y ago
[deleted]
oblio 1y ago
Occasionally the reviews match reality.

AstroJetson 1y ago

> uv is an extremely fast Python package and project manager, written in Rust. Is there a version of uv written in Python? It's weird (to me) to have an entire ecosystem for a language and a highly recommended tool to make your system work is written in another language.

ebb_earl_co 1y ago
Well, I use Debian and Bash: pretty much everything to make my system work, including and especially Python development, is written in C, another language!
dralley 1y ago
pip? A tool written in Python is never going to be as fast as one written in Rust. There are plenty of Python alternatives and you're free to use them.
sgeisenh 1y ago
Similar to ruff, uv mostly gathers ideas from other tools (with strong opinions and a handful of thoughtful additions and adjustments) and implements them in Rust for speed improvements. Interestingly, the speed is the main differentiator from existing package and project management tools. Even if you are using it as a drop-in replacement for pip, it is just so much faster.
zahlman 1y ago
They are not making a Python version. There are many competing tools in the space, depending on how you define the project requirements. Contrary to the implication of other replies, the lion's share of uv's speed advantage over Pip does not come from being written in Rust, from any of the evidence available to me. It comes from: * bootstrapping Pip into the new environment, if you make a new environment and don't know that you don't actually have to bootstrap Pip into that environment (see https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... for some hints; my upcoming post will be more direct about it - unfortunately I've been putting it off...) * being designed up front to install cross-environment (if you want to do this with Pip, you'll eventually and with much frustration get a subtly broken installation using the old techniques; since 22.3 you can just use the `--python` flag, but this limits you to environments where the current Pip can run, and re-launches a new Pip process taking perhaps an additional 200ms - but this is still much better than bootstrapping another copy of Pip!) * using heuristics when solving for dependencies (Pip's backtracking resolver is exhaustive, and proceeds quite stubbornly in order) * having a smarter caching strategy (it stores uncompressed wheels in its cache and does most of the "installation" by hard-linking these into the new environment; Pip goes through a proxy that uses some opaque cache files to simulate re-doing the download, then unpacks the wheel again) * not speculatively pre-loading a bunch of its own code that's unlikely to execute (Pip has large complex dependencies, like https://pypi.org/project/rich/ https://pypi.org/project/rich/, which it vendors without tree-shaking and ultimately imports almost all of, despite using only a tiny portion) * having faster default behaviours; e.g. uv defaults to not pre-compiling installed packages to .pyc files (since Python will do this on the first import anyway) while Pip defaults to doing so * not (necessarily) being weighed down by support for legacy behaviours (packaging worked radically differently when Pip first became publicly available) * just generally being better architected None of these changes require a change in programming language. (For example, if you use Python to make a hard link, you just use the standard library, which will then use code written in C to make a system call that was most likely also written in C.) Which is why I'm making https://github.com/zahlman/paper https://github.com/zahlman/paper .

quibono 1y ago

Last time I looked at switching from poetry to uv I had an issue with pinning certain dependencies to always install from a private PyPI repository. Is there a way to do that now? (also: possible there's always been a way and I'm an idiot)

codethief 1y ago
You mean something like https://docs.astral.sh/uv/concepts/indexes/ https://docs.astral.sh/uv/concepts/indexes/ ?
jplumail 1y ago
Yes, see: https://docs.astral.sh/uv/concepts/projects/dependencies/#index https://docs.astral.sh/uv/concepts/projects/dependencies/#in...

tyrion 1y ago

Some years ago I thought it would be interesting to develop a tool to make a python script automatically install its own dependencies (like uvx in the article), but without requiring any other external tool, except python itself, to be installed. The downside is that there are a bunch of seemingly weird lines you have to paste at the begging of the script :D If anyone is curios it's on pypi (pysolate).

dkdcio 1y ago
Also this thing that never took off: https://github.com/fal-ai/isolate https://github.com/fal-ai/isolate Not quite the same but interesting!

puika 1y ago

Like the author, I find myself going more for cross-platform Python one-offs and personal scripts for both work and home and ditching Go. I just wish Python typechecking weren't the shitshow it is. Looking forward to ty, pyrefly, etc. to improve the situation a bit

SavioMak 1y ago
Speed is one thing, the type system itself is another thing, you are basically guaranteed to hit like 5-10 issues with python's weird type system before you start grasping some of the oddities
ViscountPenguin 1y ago
I've never particularly liked go for cross platform code anyway. I've always found it pretty tightly wedded to Unix. Python has its fair share of issues on windows aswell though, I've been stuck debugging weird .DLL issues with libraries for far too long in my life. Strangely, I've found myself building personal cross platform apps in game engines because of that.
silverwind 1y ago
I do hope the community will converge on one type checker like ty. The fact that multiple type checkers exist is really hindering to the language as a whole.
davidatbu 1y ago
I wouldn't describe Python type checking as a shit-show. pyright is pretty much perfect. One nit against it perhaps is that it doesn't support non-standard typing constructs like mypy does (for Django etc). That's an intentional decision on the maintainer's part. And I'm glad he made that decision because that spurned efforts to make the standard typing constructs more expressive. I'm also looking forward to the maturity of Rust-based type checkers, but solely because one can almost always benefit from an order of magnitude improvement in speed of type checking, not because Python type-checking is a "shit show". I do grant you that for outsiders, the fact that the type checker from the Python organization itself is actually a second rate type checker (except for when one uses Django, etc, and then it becomes first-rate) is confusing.

divbzero 1y ago

If momentum for uv in the community continues, I’d love to see it distributed more broadly. uv can already be installed easily on macOS via Homebrew (like pyenv). uv can also be installed on Windows via WinGet (unlike pyenv). It would be nice to see it packaged for Linux as well.

mixmastamyk 1y ago
$ dnf search --cacheonly uv Matched fields: name (exact) uv.x86_64: An extremely fast Python package installer and resolver, written in Rust

mont_tag 1y ago

Grace Hopper technology: A well formed Python program shall define an ENVIRONMENT division that specifies the environment in which the program will be compiled and executed. It outlines the hardware and software dependencies. This division is crucial for making COBOL^H^H^H^H^HPython programs portable across different systems.

bjourne 1y ago

> For the longest time, I have been frustrated with Python because I couldn’t use it for one-off scripts. Bruh, one-off scripts is the whole point of Python. The cheat code is to add "break-system-packages = true" to ~/.config/pip/pip.conf. Just blow up ~/.local/lib/pythonX.Y/site-packages/ if you run into a package conflict (exceedingly rare) and reinstall. All these venv, uv, metadata peps, and whatnot are pointless complications you just don't need.

kristianp 1y ago

If you want to manually manage envs and you're using conda, you can activate the env in a shell wrapper for your python script, like so (this is with conda) #!/usr/bin/env bash eval "$(conda shell.bash hook)" conda activate myenv python myscript Admittedly this isn't self contained like the PEP 723 solution.

divbzero 1y ago

This is very cool. Note that PEP 723 is also supported by pipx run: https://pipx.pypa.io/latest/examples/#pipx-run-examples https://pipx.pypa.io/latest/examples/#pipx-run-examples

gerdesj 1y ago

I've recently updated a Python script that I originally wrote about 10 years ago. I'm not a programmer - I just have to get stuff done - think sysops. For me there used to be a clear delineation between scripting languages and compiled languages. Python has always seemed to want to be both and I'm not too sure it can really. I can live with being mildly wrong about a concept. When Python first came out, our processors were 80486 at best and RAM was measured in MB at roughly £30/MB in the UK. "For the longest time, ..." - all distros have had scripts that find the relevant Python or Java or whatevs so that's simply daft. They all have shebang incantations too. So we now have uv written in Rust for Python. Obviously you should install it via a shell script directly from curl! I love all of the components involved here but please for the love of a nod to security at least suggest that the script is downloaded first, looked over and then run. I recently came across a Github hosted repo with scripts that changed Debian repos to point somewhere else and install ... software. I'm sure that's all fine too. curl | bash is cute and easy and very, very insecure.

wiseowise 1y ago
> Obviously you should install it via a shell script directly from curl! No? You can install it via pip.
- benrutter 1y ago
  You can do both but the official recomendation is shell + curl[0]. Not an expert but I think there's performance gains to calling the binary directly rather than through python. [0]: https://docs.astral.sh/uv/ https://docs.astral.sh/uv/
- gerdesj 1y ago
  I was going off on a bit of a tangent but take a look at this horror, which is still up: https://github.com/InboraStudio/Proxmox-VGPU https://github.com/InboraStudio/Proxmox-VGPU Note the quite professional looking README.md and think about the audience for this thing - kittens hitting the search bong and trying to get something very complicated working. Read the scripts: they are pretty short and could put your hypervisor in the hands of someone else who may not be too friendly. Now pip has the same problem except you don't normally go in with a web browser first. I raised an issue to at least provide a hint to casual browsers and also raised it with the github AI bottie complaint thang which doesn't care about you, me or anything else for that matter.

4dregress 1y ago

I’ve been a python dev for nearly a decade and never once thought dep management was a problem. If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell . So I still don’t see what the fuss is about? I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI setup times.

petersellers 1y ago
> it’s always been done in that ENVs python shell . What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.
- kinow 1y ago
  I wrote PHP/JS/Java before Python. Been doing Python for nearly a decade too, and like 4dregress haven't had the need to worry much about dep management. JS and PHP had all sorts of issues, Maven & Gradle are still the ones that gave me less trouble. With Python I found that most issues could be fixed by finding the PEP that implemented what I needed, and by trying to come up with a simple workflow & packaging strategy. Nowadays I normally use `python venv/bin/<some-executable>`, or `conda run -n <some-env> <some-executable>`, or packaged it in a Singularity container. And even though I hear a lot of good things about uv, given that my job uses public money for research, we try to use open source and standards as much as possible. My understanding is that uv is still backed by a company, and at least when I checked it some time ago (in peps discussions & GH issues) they were no implementing the PEPs that I needed -- even if they did, we would probably still stay with simple pip/setuptools to avoid having to use research budget to update our build if the company ever changed its business model (e.g. what anaconda did some months/year? ago). Digressing: the Singularity container is useful for research & HPC too, as it creates a single archive, which is faster to load on distributed filesystems like the two I work on (GPFS & LustreFS) instead of loading many small files over network.
- arcanemachiner 1y ago

rednafi 1y ago

> Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable. I still do because: - Go gives me a single binary - Dependencies are statically linked - I don’t need any third-party libs in most scenarios - Many of my scripts make network calls, and Go has a better stdlib for HTTP/RPC/Socket work - Better tooling (built-in formatter, no need for pytest, go vet is handy) - Easy concurrency. Most of my scripts don’t need it, but when they do, it’s easier since I don’t have to fiddle with colored functions, external libs, or, worse, threads. That said, uv is a great improvement over the previous status quo. But I don’t write Python scripts for reasons that go beyond just tooling. And since it’s not a standard tool, I worry that more things like this will come along and try to “improve” everything. Already scarred and tired in that area thanks to the JS ecosystem. So I tend to prefer stable, reliable, and boring tools over everything else. Right now, Go does that well enough for my scripting needs.

7bit 1y ago
Good for you. I dont See how this is relevant to this topic.
- rednafi 1y ago
  > Before this I used to prefer Go for one-off scripts because it was easy to create a self-contained binary executable. Here's how it's relevant :)
deepakjois 1y ago
(author of post here) I still use both Go and Python. But Python gives me access to a lot more libraries that do useful stuff. For example the YouTube transcript example I wrote about in the article was only possible in Python because afaik Go doesn't have a decent library for transcript extraction.
- rednafi 1y ago
  Yeah that's a fair point. I still do a ton of Python for work. The language is fine; it's mostly tooling that still feels 30 years old.

zidoo 1y ago

My only question is: who asked for faster pip?

0x008 1y ago
Comparing apples and orange here. Uv scope is so much more than pip
TypingOutBugs 1y ago
uv has a lot more perks! It makes distributing python tooling easier too

syhol 1y ago

Mise has a very similar feature with its shebangs: https://mise.jdx.dev/tips-and-tricks.html#shebang https://mise.jdx.dev/tips-and-tricks.html#shebang #!/usr/bin/env -S mise x xh jq fzf gum -- bash todo=$(xh 'https://jsonplaceholder.typicode.com/todos' | jq '.[].title' | fzf) gum style --border double --padding 1 "$todo" It makes throwing together a bash scripts with dependencies very enjoyable

zelphirkalt 1y ago

Using Guix (guix shell) it was already possible to run Python scripts one-off. I see others have also commented about doing it using Nix. Also that would be reproducible, in contrast to what is shown in the blog post. To make that reproducible, one would have to keep the lock file somewhere, or state the checksums directly in the Python script file, which seems rather un-fun.

Imustaskforhelp 1y ago

I have a lot of opinions about this. Firstly, I have been a HN viewer for so many time and this is the one thing about pep python scripts THAT always get to the top of leaderboard of hackernews by each person discovering it themselves. I don't mean to discredit the author. His work was simple and clear to understand. I am just sharing this thesis that I have that if someone wants karma on Hackernews for whatever reason, this might be the best topic. (Please don't pitchfork me since I don't mean offense to the author) Also, can anybody please explain to me on how to create that pep metadata in uv from just a python script and without anything else, like some command which can take a python script and give pep and add that in the script, I am pretty sure that uv has a feature flag but I feel that the author might've missed out on this feature because I don't know when coding one off scripts in python using AI (gemini) it had some options with pep so I always had to paste uv's documentation I don't know, so please if anybody knows a way to create pep easier using the cli, then please tell me! Thanks in advance!!

altbdoor 1y ago
One can use uv to add into the dependencies list $ touch foo.py $ uv add --script foo.py requests Updated `foo.py` $ cat foo.py # /// script # requires-python = ">=3.13" # dependencies = [ # "requests", # ] # ///
- Imustaskforhelp 1y ago
  Thanks a lot friend, But one of the issues with this is that I need to know about requests and sometimes their names can be different and I actually had created a cli tool called uvman which actually wanted to automate that part too. But my tool was really finnicky and I guess it was built by AI ,so um yea, I guess you all can try it, its on pypi. I think that it has a lot of niche cases where it doesn't work. Maybe someone can modify it to make it better as I had built it like 3-4 months ago if I remember correctly and I have completely forgotten how things worked in uv.

pseudosavant 1y ago

Between how good ChatGPT/Claude are at writing Python, and discovering uv + PEP 723, I'm creating all sorts of single file python scripts. Some of my recent personal tools: compression stats for resources when gzipped, minify SVGs, a duplicate file tool, a ping testing tool, a tool for processing large CSVs through LLMs one row at a time, etc. uv is the magic that deals with all of the rough edges/environment stuff I usually hate in Python. All I need to do is `uv run myFile.py` and uv solves everything else.

jasonm23 1y ago

This seems timely, `uv` is a complete revelation for me and has made working with Python extremely convenient ... the Python "just works" time has arrived. I'm building yt-dlp / uvx based WebUI - https://github.com/ocodo/uvxytdlp https://github.com/ocodo/uvxytdlp Still work in progress but shaping up nicely.

timkofu 1y ago

Nice.