[HN Gopher] Fun with uv and PEP 723
___________________________________________________________________
Fun with uv and PEP 723
Author : deepakjois
Score : 243 points
Date : 2025-06-24 18:41 UTC (4 hours ago)
(HTM) web link (www.cottongeeks.com)
(TXT) w3m dump (www.cottongeeks.com)
| jkingsman wrote:
| 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 wrote:
| Truly. uv somehow resolves and installs dependencies more
| quickly than pyenv manages to print its own --help output.
| mikepurvis wrote:
| 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 wrote:
| 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 wrote:
| There's a launcher wrapper shell script + Python startup
| time that contributes to pyenv's slow launch times.
| theshrike79 wrote:
| The "slowness" and the utter insanity of trying to make a
| "works on my computer" Python program work on another
| computer pushed me to just rewrite all my Python stuff in
| Go.
|
| About 95% of my Python utilities are now Go binaries cross-
| compiled to whatever env they're running in. The few
| remaining ones use (API) libraries that aren't available
| for Go or aren't mature enough for me to trust them yet.
| Spivak wrote:
| Not to derail the Python speed hate train but pyenv is
| written in bash.
|
| It's a tool for installing different versions of Python, it
| would be weird for it to assume it already had one
| available.
| lxgr wrote:
| Oh, that might actually explain the slow line printing
| speed. Thank you, solves a long standing low stakes
| mystery for me :)
| heavyset_go wrote:
| Last time I looked, pyenv contributors were considering
| implementing a compiled launcher for that reason.
|
| But that ship has sailed for me and I'm a uv convert.
| Noumenon72 wrote:
| 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 wrote:
| PEP 723 was incorporated (with modifications) into the official
| Python packaging specifications:
| 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 wrote:
| 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 wrote:
| PEP 723 is final and most relevant tools will support it:
|
| https://discuss.python.org/t/40418/82
| k__ wrote:
| 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 wrote:
| I think they must have been joking!
| wavemode wrote:
| 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 wrote:
| 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 wrote:
| 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.
| epistasis wrote:
| 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/
|
| And there was a March discussion of a different blog post:
|
| https://news.ycombinator.com/item?id=43500124
|
| I hope this stays on the front page for a while to help publicize
| it.
| lysace wrote:
| Why do I feel like I'm _in_ an infomercial?
| _visgean wrote:
| I honestly don't like that this is expressed as a comment but I
| guess it makes the implementation easy and backwards
| compatible...
| ACAVJW4H wrote:
| finally feels like Python scripts can Just Work(tm) 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 wrote:
| Consider porting your shell scripts to Python? The language is
| vastly superior and subprocess.check_call is not so bad.
| SmellTheGlove wrote:
| Would homebrew do the job?
| ndr wrote:
| 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/ check it out
| if you like Clojure.
| bigstrat2003 wrote:
| > 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.
| bjackman wrote:
| For the specific case of solving shell script dependencies, Nix
| is actually very straightforward. Packaging a script is a
| writeShellApplication call and calling it is a `nix run`.
|
| I guess the issue is just that nobody has documented how to do
| that one specific thing so you can only learn this technique by
| trying to learn Nix as a whole.
|
| So perhaps the thing you're envisaging could just be a wrapper
| for this Nix logic.
| pxc wrote:
| I use Nix for this with resholve and I like it a lot.
| traverseda wrote:
| I don't think nix is that hard for this particular use case.
| Installing nix on other distros is pretty easy, and once it's
| installed you just do something like this #!
| /usr/bin/env nix-shell #! nix-shell -i bash -p
| imagemagick cowsay # scale image by 50%
| convert "$1" -scale 50% "$1.s50.jpg" && cowsay "done
| $1.q50.jpg"
|
| Sure all of nixos and packaging for nix is a challenge, but
| just using it for a shell script is not too bad
| password4321 wrote:
| I'm unable to resist responding that clearly the solution is to
| run Nix in Docker _as_ your shell since packaging, dependency
| management, and reproducibility will be at theoretical maximum.
| ravenical wrote:
| https://web.archive.org/web/20250624191820/https://www.cotto...
| hifikuno wrote:
| Thanks! I'm guessing it's blocked on your work/uni network too?
| Stupid over-eager firewall.
| doctoboggan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zahlman wrote:
| > Deploying Python projects almost require using a container.
|
| Really? `apt install pipx; pipx install sphinx` (for example)
| worked flawlessly for me. Pipx is really just an opinionated
| wrapper that invokes a vendored copy of Pip and the standard
| library `venv`.
|
| The rest of your post seems to acknowledge that virtual
| environments generally work just fine. (Uv works by creating
| them.)
|
| > Sometimes you're limited by Python version and it can be
| non-trivial to have multiple versions installed at once.
|
| I built them from source and make virtual environments off of
| them, and pass the `--python` argument to Pipx.
|
| > 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.
|
| If you're letting it install separate copies of Python, sure.
| (The main use case for pyenv is getting _one_ separate copy
| of each Python version you need, if you don 't want to build
| from source, and then managing virtual environments based off
| of that.) If you're letting it bootstrap Pip into the virtual
| environment, sure. But you don't need to do either of those
| things. Pip can install cross-environment since 22.3 (Pipx
| relies on this).
|
| Uv _does_ save disk space, especially if you have multiple
| virtual environments that use the same packages, by hard-
| linking them.
|
| > 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.
|
| Pipx implements PEP 723, which was written to be an
| ecosystem-wide standard.
| padjo wrote:
| I'm a moron when it comes to python tooling but switching a
| project to uv was a pleasant experience. It seems well thought
| out and the speed is genuinely a feature compared to other
| python tooling I've used.
| zahlman wrote:
| A lot of people like all-in-one tools, and uv offers an
| opinionated approach that works. It's essentially the last
| serious attempt at this since Poetry, except that uv is also
| supporting a variety of new Python packaging standards up front
| (most notably https://peps.python.org/pep-0621/ , which Poetry
| lagged on for years - see https://github.com/python-
| poetry/roadmap/issues/3 ) and seems committed to keeping on top
| of new ones.
|
| How much you can benefit depends on your use case. uv is a
| developer tool that also manages installations of Python itself
| (and maintains separate environments for which you can choose a
| Python version). If you're just trying to install someone
| else's application from PyPI - say
| https://pypi.org/project/pycowsay/ as an example - you'll
| likely have just as smooth of an experience via pipx (although
| installation will be even slower than with pip, since it's
| using pip behind the scenes and adding its own steps). On the
| other hand, to my understanding, to use uv as a developer
| you'll still need to choose and install a build backend such as
| Flit or Hatchling, or else rely on the default Setuptools.
|
| One major reason developers are switching to uv is lockfile
| support. It's worth noting here that an interoperable standard
| for lockfiles was recently approved
| (https://peps.python.org/pep-0751/), uv will be moving towards
| it, and other tools like pip are moving towards supporting it
| (the current pip can write such lockfiles, and installing from
| them is on the roadmap:
| https://github.com/pypa/pip/issues/13334).
|
| If you, like me, prefer to follow the UNIX philosophy, a
| complete developer toolchain in 2025 looks like:
|
| * Python itself (if you want standalone binaries like the ones
| uv uses, you can get them directly; you can also build from
| source like I do; if you want to _manage_ Python installations
| then https://github.com/pyenv/pyenv is solid, or you can use
| the multi-language https://asdf-vm.com/guide/introduction.html
| with https://github.com/asdf-community/asdf-python I guess)
|
| * Ability to create virtual environments (the standard library
| takes care of this; some niche uses are helped out by
| https://virtualenv.pypa.io/)
|
| * Package installer (Pip can handle this) and manager (if you
| really want something to "manage" packages by installing into
| an environment and simultaneously updating your pyproject.toml,
| or things like that; but just fixing the existing environment
| is completely viable, and installers already resolve
| dependencies for whatever it is they're currently installing)
|
| * Build frontend (the standard is
| https://build.pypa.io/en/stable/; for programmatic use, you can
| work with https://pyproject-hooks.readthedocs.io/en/latest/
| directly)
|
| * Build backend (many options here - by design! but installers
| will assume Setuptools by default, since the standard requires
| them to, for backwards compatibility reasons)
|
| * Support for uploading packages to PyPI (the standard is
| https://twine.readthedocs.io/en/stable/)
|
| * Optional: typecheckers, linters, an IDE etc.
|
| A _user_ on the other hand only needs
|
| * _Some_ version of Python (the one provided with a typical
| Linux distribution will generally work just fine; Windows users
| should usually just install the current version, with the
| official installer, unless they know something they want to
| install isn 't compatible)
|
| * Ability to create virtual environments and also install
| packages into them (https://pipx.pypa.io/stable/ takes care of
| both of these, as long as the package is an "application" with
| a defined entry point; I'm making
| https://github.com/zahlman/paper which will lift that
| restriction, for people who want to `import` code but not
| necessarily publish their own project)
|
| * Ability to actually run the installed code (pipx handles this
| by symlinking from a standard application path to a wrapper
| script inside the virtual environment; the wrappers specify the
| absolute path to the virtual environment's Python, which is
| generally all that's needed to "use" that virtual environment
| for the program. It also provides a wrapper to run Pip within a
| specific environment that it created. PAPER will offer
| something a bit more sophisticated here, for both aspects.)
| codethief wrote:
| Yes, IMO it does. I wrote my first lines of Python 16 years ago
| and have worked with raw pip & venv, PDM and Poetry. None of
| those solutions come close to how easy it is to use (and
| migrate to) uv. Just give it a try for half an hour, you likely
| won't want to use anything else after that.
| sambaumann wrote:
| 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 wrote:
| 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 wrote:
| 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/).
|
| (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.)
| gschizas wrote:
| > 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/)
| tdhopper wrote:
| 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....
| 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!
| wrboyce wrote:
| This would've been really handy for me a few weeks ago when I
| ended up working this out for myself (not a huge job, but
| more effort than reading your documentation would've been).
| While I can't think of anything missing off the top of my
| head, I do think a PR to uv to update the official docs would
| help a lot of folk!
|
| Actually, I've thought of something! Migrating from poetry!
| It's something I've been meaning to look at automating for a
| while now (I really don't like poetry).
| oconnor663 wrote:
| > it's defined in both .python-version and pyproject.toml
|
| The `requires-version` field in `pyproject.toml` defines a
| _range_ of compatible versions, while `.python-version` defines
| the specific version you want to use for development. If you
| create a new project with uv init, they 'll look similar
| (>=3.13 and 3.13 today), but over time `requires-version`
| usually lags behind `.python-version` and defines the _minimum_
| supported Python version for the project. `requires-version`
| also winds up in your package metadata and can affect your
| callers ' dependency resolution, for example if your published
| v1 supports Python 3.[old] but your v2 does not.
| zahlman wrote:
| > how to define a python version for a specific project (it's
| defined in both .python-version and pyproject.toml)
|
| pyproject.toml is about allowing _other_ developers, and end
| users, to use your code. When you share your code by packaging
| it for PyPI, a build backend (uv is not one, but they seem to
| be working on providing one - see https://github.com/astral-
| sh/uv/issues/3957 ) creates a distributable package, and
| pyproject.toml specifies what environment the user needs to
| have set up (dependencies and python version). It has _nothing
| to do with_ uv in itself, and is an interoperable Python
| ecosystem standard. A range of versions is specified here,
| because other people should be able to use your code on
| multiple Python versions.
|
| The .python-version file is used to tell uv specifically (i.e.
| nobody else) specifically (i.e., exact version) what to do when
| _setting up your_ development environment.
|
| (It's perfectly possible, of course, to just use an already-
| set-up environment.)
| gigatexal wrote:
| 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 wrote:
| Does this create a separate environment for each script? If so,
| won't that create lots of bloat?
| JimDabell wrote:
| 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.
| zahlman wrote:
| 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 wrote:
| 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
| deepakjois wrote:
| C# too: https://devblogs.microsoft.com/dotnet/announcing-
| dotnet-run-...
| kzrdude wrote:
| 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.
| korijn wrote:
| 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 wrote:
| PEP 723 allows you to specify version numbers for direct
| dependencies, but of course indirect dependencies aren't
| guaranteed to be the same.
| js2 wrote:
| > 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-dependenci...
|
| https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...
| zahlman wrote:
| > 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 wrote:
| 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.
| ali1ism wrote:
| In Ruby, this feature is built-in with its default package
| manager: [bundler/inline](https://bundler.io/guides/bundler_in_a_
| single_file_ruby_scri...).
| babuloseo wrote:
| been doing this with Pipenv before, but uv is like Pipenv on
| steroids.
| js2 wrote:
| 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 wrote:
| 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 wrote:
| This is rather silly.
| dkdcio wrote:
| 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/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 wrote:
| > 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 wrote:
| 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 wrote:
| What's going on? This whole thread reads like paid amazon reviews
| indosauros wrote:
| What's going on is "we have 14 standards so we need to create a
| 15th" actually worked this time
| kibwen wrote:
| 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.
| oblio wrote:
| Occasionally the reviews match reality.
| AstroJetson wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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-...
| 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/, 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 .
| jaapz wrote:
| But also, because it's written in rust. There are tools
| written in python that do these smart caching and resolving
| tricks as well, and they are still orders of magnitude slower
| quibono wrote:
| 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 wrote:
| You mean something like
| https://docs.astral.sh/uv/concepts/indexes/ ?
| jplumail wrote:
| Yes, see:
| https://docs.astral.sh/uv/concepts/projects/dependencies/#in...
| tyrion wrote:
| 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 wrote:
| Also this thing that never took off: https://github.com/fal-
| ai/isolate
|
| Not quite the same but interesting!
| puika wrote:
| 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
___________________________________________________________________
(page generated 2025-06-24 23:00 UTC)