Ok, so apparently `uv` has nothing to do with `libuv`.
A year of uv: pros, cons, and should you migrate
281–290 of 401 posts
Re: A year of uv: pros, cons, and should you migrate
#282Earlier quoted context omitted.
Cross platform Java doesn't have the issue because the JVM is handling all of that for you. But if you want native extensions written in C you get back to the same problem pretty quickly.
> if you want native extensions written in C The SQLite project I linked to is a JDBC driver that makes use of the C version of the library appropriate to each OS. LWJGL ( https://repo1.maven.org/maven2/org/lwjgl/lwjgl/3.3.6/ ) is another project which heavily relies on native code. But distributing these, or using these as dependencies, does not result in hair-pulling like it does with python.
There's native code like SQLite which assuming a sensible file system and C compiler is quite portable, and then there's native code which cares about exact compiler versions, driver version, and the exact model of your CPU, GPU and NIC. My suggestion is go look at how to program a GPU using naive vulkan/metal, and then look for the dark magic that is used to make GPUs run fast. It's the latter you're encountering with the ML python projects.
Re: A year of uv: pros, cons, and should you migrate
#283Author here. A.m.a
Re: A year of uv: pros, cons, and should you migrate
#284I think at this point, the only question it remains is how Astral will make money. But if they can package some sort enterprise package index with some security bells and whistles it seems an easy sell into a ton of orgs.
Charlie Marsh said in our interview they plan to compete with anaconda on b2b:
https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...
Make sense, the market is wide open for it.
Re: A year of uv: pros, cons, and should you migrate
#285Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add n…
> The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow.
First, let me try to make sense of it for you -
One of uv's big ideas is that it has a much better approach to caching downloaded packages, which lets it create those environments much more quickly. (I guess things like "written in Rust", parallelism etc. help, but as far as I can tell most of the work is stuff like hard-linking files, so it's still limited by system calls.) It also hard-links duplicates, so that you aren't wasting tons of space by having multiple environments with common dependencies.
A big part of the point of making separate environments is that you can track what each project is dependent on separately. In combination with Python ecosystem standards (like `pyproject.toml`, the inline script metadata described by https://peps.python.org/pep-0723/, the upcoming lock file standard in https://peps.python.org/pep-0751/, etc.) you become able to reproduce a minimal environment, automate that reproduction, and create an installable sharable package for the code (a "wheel", generally) which you can publish on PyPI - allowing others to install the code into an environment which is automatically updated to have the needed dependencies. Of course, none of this is new with `uv`, nor depends on it.
The installer and venv management tool I'm developing (https://github.com/zahlman/paper) is intended to address use cases like yours more directly. It isn't a workflow tool, but it's intended to make it easier to set up new venvs, install packages into venvs (and say which venv to install it into) and then you can just activate the venv you want normally.
(I'm thinking of having it maintain a mapping of symbolic names for the venvs it creates, and a command to look them up - so you could do things like "source `paper env-path foo`/bin/activate", or maybe put a thin wrapper around that. But I want to try very hard to avoid creating the impression of implementing any kind of integrated development tool - it's an integrated user tool, for setting up applications and libraries.)
Re: A year of uv: pros, cons, and should you migrate
#286Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.
"It's written in Rust" is not responsible for most of the improvements on offer here. (TFA barely mentions Rust, to its credit.) Many of them come from algorithmic improvements, better design decisions, and simply just not having the tool reside in the same environment as the installation target. (It is perfectly possible to use Pip cross-environment like this, too. People just don't do it, because a) they don't know and b) the standard library `venv` and `ensurepip` tools are designed to bootstrap Pip into new virtual environments by default. My recent blog post https://zahlman.github.io/posts/2025/01/07/python-packaging-... offers relevant advice here, and upcoming posts are in the works and/or planned about design issues in Pip.)
If your purpose is to denigrate Python as a language, then uv isn't solving problems for you anyway. But I will say that the kind of evangelism you're doing here is counterproductive, and is the exact sort of thing I'd point to when trying to explain why the project of integrating Rust code into the Linux kernel has been so tumultuous.
Re: A year of uv: pros, cons, and should you migrate
#287Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.
> And I had to deal with Scala's SBT ("Simple Build Tool") in another life. I feel you.
For someone who was just about to give Scala a try, what's wrong with it and are there alternative build tools?
Re: A year of uv: pros, cons, and should you migrate
#288Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.
Yeah, if Python sucks at managing its own packages and you need Rust, why use Python at all?
That's the thing: you don't actually need Rust. uv has simply chosen it as an implementation language, but there isn't anything about Python that inherently prevents it from being used to write tools better than Pip. The problems with Pip are problems with Pip, not problems with Python.
(And many of them are completely fake, anyway. You don't actually need to spend an extra 15MB of space, and however many seconds of creation time, on a separate copy of Pip in each venv just so that Pip can install into that venv. You just need the `--python` flag. Which is a hack, but an effective one.)
(Last I checked, the uv compiled binary is something like 35MB. So sticking with a properly maintained Pip cuts down on that. And Pip is horrendously bloated, as Python code goes, especially if you only have the common use cases.)
Re: A year of uv: pros, cons, and should you migrate
#289Earlier quoted context omitted.
You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.
While working in Django projects, one would prefer to have an environment activarted to perform all kinds of django-admin commands, I certainly wouldn't want to do via `uv run`. Also, `nvim` is started with an environment activated if you want all the LSP goodies. `uv run` is good for some things, but I prefer to have my venv activated as well.
Soon uv will invlude a task runner that will take care of that use case but I get your point.
Re: A year of uv: pros, cons, and should you migrate
#290Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.
"It's written in Rust" is not responsible for most of the improvements on offer here. (TFA barely mentions Rust, to its credit.) Many of them come from algorithmic improvements, better design decisions, and simply just not having the tool reside in the same environment as the installation target. (It is perfectly possible to use Pip cross-environment like this, too. People just don't do it, because a) they don't know…
Do you think that pip could be re-implemented in Python and it would result in this performance that we are observing with uv?