Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

Post reply on HN
Print view View original

331–340 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#331

Post by dekhn »

jvanderbot wrote: post #178
dekhn wrote: post #58

I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly. My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can't reproduce anything because just to…

Obligatory: Not only rust would be faster than python, but Rust definitely makes it easy with Cargo. Go, C, C++ should all exhibit the performance you are seeing in uv, if it had been written in one of those languages. The curmudgeon in me feels the need to point out that fast, lightweight software has always been possible, it's just becoming easier now with package managers.

I've programmed all those languages before (learned C in '87, C++ in 93, Go in 2015 or so) and to be honest, while I still love C, I absolutely hate what C++ has become, Go never appealed to me (they really ignored numeric work for a long time). Rust feels like somebody wanted to make a better C with more standard libraries, without going the crazy path C++ took.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#332

Post by forrestthewoods »

uv is spectacular

But I’m utterly shocked that UV doesn’t support “system dependencies”. It’s not a whole conda replacement. Which is a shame because I bloody hate Conda.

Dependencies like Cuda and random C++ libraries really really ought to be handled by UV. I want a true genuine one stop shop for running Python programs. UV is like 80% of the way there. But the last 20% is still painful.

Ideally UV would obsolete the need for docker. Docker shouldn’t be a requirement to reliable run a program.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#333

Post by brailsafe »

hardwaregeek wrote: post #247
caconym_ wrote: post #227

Earlier quoted context omitted.

There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.

Never underestimate cultural momentum I guess. NBA players shot long 2 pointers for decades before people realized 3 > 2. Doctors refused to wash their hands before doing procedures. There’s so many things that seem obvious in retrospect but took a long time to become accepted

[flagged]

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#334

Post by embeng4096 »

Areibman wrote: post #328

My biggest frustration is the lack of a good universal REPL to just play around with. It's frustrating how I have to run `uvx --with x,y,z ipython` every single time I just want to spin up some python code which may or may not use packages. (Hard to overstate how annoying it is to type out the modules list). To me, Python's best feature is the ability to quickly experiment without a second thought. Conda is nice sinc…

Would creating a `main.py` with the dependencies installed either as a uv project or inline work for you?

One thing I did recently was create a one-off script with functions to exercise a piece of equipment connected to the PC via USB, and pass that to my coworkers. I created a `main.py` and uv add'ed the library. Then when I wanted to use the script in the REPL, I just did `uv run python -i main.py`.

This let me just call functions I defined in there, like `set_led_on_equipment(led='green', on=True)` directly in the REPL, rather than having to modify the script body and re-run it every time.

Edit: another idea that I just had is to use just[0] and modify your justfile accordingly, e.g. `just pything` and in your justfile, `pything` target is actually `uv run --with x,y,z ipython`

Edit edit: I guess the above doesn't even require just, it could be a command alias or something, I probably am overengineering that lol.

[0]: https://github.com/casey/just

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#335

Post by ASalazarMX »

nullbyte wrote: post #245
chrisweekly wrote: post #214

Earlier quoted context omitted.

Webdev since 1998 here. Tabling the python vs JS/etc to comment on npm per se. PNPM is better than npm in every way. Strongest possible recommendation to use it instead of npm; it's faster, more efficient, safer, and more deterministic. See https://pnpm.io/motivation

I find pnpm annoying to type, that's why I don't use it

Command alias? Even Windows can do them these days.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#336

Post by collinmanderson »

isodev wrote: post #123

Or is it a corporate grab to gain more influence in the ecosystem? I like the idea, but for profit backing is out of the question. This lesson has been learned countless times.

They plan on making money by running private package registries, rather than making money on the client. https://astral.sh/pyx

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#338

Post by the8472 »

zahlman wrote: post #312
the8472 wrote: post #196

Earlier quoted context omitted.

What's wrong? Having modify the shell environment, no lockfile, slow download/installation, lack of a standard dependency dir, ... > I'd get suspicious if a developer is picky about python versions or library versions Certain library versions only support certain python versions. And they also break API. So moving up/down the python versions also means moving library versions which means stuff no longer works.

You don't have to modify the environment (this is provided as an option for convenience). The alternatives are to use higher-level management like uv does, or to specify the path to executables in the virtual environment directly. But uv works by creating virtual environments that are essentially the same as what you get with `python -m venv --without-pip` (although they reimplemented the venv creation logic). Pip ca…

I'm confused by this reply.

> The alternatives are to use higher-level management like uv does,

The question was specifically what's wrong with pip, venv and pyproject toml, i.e. what issues uv is trying to address. Well of course the thing trying to address the problem addresses the problem....

> I don't know what you mean about a "standard dependency dir".

like node's node_modules, or cargo's ~/.cargo/registry. You shouldn't have to manually create and manage that. installing/building should just create it. Which is what uv does and pip doesn't.

> the same as what you get with `python -m venv --without-pip`

The thing that should be automatic. And even if it is not it should at least be less arcane. An important command like that should have been streamlined long ago. One of the many improvements uv brings to the table.

> and work is under way to allow it to install from those lockfiles as well.

Yeah well, the lack up until now is one of those "what is wrong" things.

> But your download speed is still going to be primarily limited by your internet connection to PyPI.

Downloading lots of small packages dependencies serially leaves a lot of performance on the table due to latency and non-instantaneous response from congestion controllers. Downloading and installing concurrently reduces walltime further.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#339

Post by zahlman »

tonymet wrote: post #273

Can someone steelman the python tooling ecosystem for me? Having a new packaging / dependency manager every few years seems excessive.

All of these tools are third-party and the Python core development team can't do anything to prevent people from inventing new ones. Even pip is technically at arms length; it has special support in the standard library (Python releases will vendor a wheel for it, which is designed to be able to bootstrap itself for installation[0]), but is developed separately.

Standards are developed to allow existing tools to inter-operate; this entails allowing new tools to appear (and inter-operate), too.

This system was in some regards deliberate, specifically to support competition in "build backends". The background here is that many popular Python projects must interface to non-Python code provided with the project; in many cases this is code in compiled languages (typically C, Fortran or Rust) and it's not always possible to pre-build for the user's system. This can get really, really complicated, and people need to connect to heavyweight build systems in some cases. The Python ecosystem standards are designed with the idea that installers can automatically obtain and use those systems when necessary.

And by doing all of this, Python core developers get to focus on Python itself.

Another important concern is that some bad choices were made initially with Setuptools, and we have been seeing a very long transition because of a very careful attitude towards backwards compatibility (even if it doesn't seem that way!) which in turn is motivated by the battle scars of the 2->3 transition. In particular, it used to be normal and expected that your project would use arbitrary Python code (in `setup.py` at the project root) simply to specify metadata. Further, `setup.py` generally expects to `import setuptools`, and might require a specific version of Setuptools; but it can't express its build-time Setuptools version requirement until the file is already running - a chicken-and-egg scenario.

Modern projects use a declarative TOML file for "abstract" metadata instead (which is the source for concrete metadata included in the actual build artifacts), but the whole ecosystem still has to support a lot of really outdated ways of doing things, because in part of how much abandonware is out there.

[0]: Wheels are zip-compressed, and Python can run code from a zip file, with some restrictions. The pip project is designed to make sure that this will work. The standard library provides a module "ensurepip" which locates this wheel and runs a bootstrap script from that wheel, which will then install into the current environment. Further, the standard library "venv", used to create virtual environments, defaults to using this bootstrap in the newly created environment.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#340

Post by odyssey7 »

hardwaregeek wrote: post #149

I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing

Python might have been better at this but the community was struggling with the 2 vs 3 rift for years. Maybe new tooling will change it, but my personal opinion is that python does not scale very well beyond a homework assignment. That is its sweet spot: student-sized projects.
Post reply on HN