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

931–940 of 1001 posts

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

#931

Post by zahlman »

bschwindHN wrote: post #586
1718627440 wrote: post #361

Earlier quoted context omitted.

It does, Python has essentially solved it for years.

lol no it hasn't Why else is this discussion getting hundreds of comments? For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.

> For any random python tool out there, I had about a 60% chance it would work out of the box.

Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on.

> uv is the first tool in the python ecosystem that has brought that number basically to 100%.

Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip.

> Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.

I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).

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

#932

Post by 12_throw_away »

Helmut10001 wrote: post #929

Does anyone know how Uv performs in the Geo-Package-Space? (i.e. GDAL, geopandas, cartopy, pyproj, rasterio etc.) This is the one area where I still find that conda performs best because all the authors of these packages use the conda-forge channel themselves for testing and production.

I believe the actual packaging technology is no different from pip - so if these packages don't install cleanly with `pip`, they won't install cleanly with `uv pip` either. If you need conda packages, uv isn't planning on supporting them [1].

[1] https://github.com/astral-sh/uv/issues/1703

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

#933

Post by Mawr »

pama wrote: post #786
tiagod wrote: post #524

Earlier quoted context omitted.

What's the difference from going to the website and downloading it, or doing it through the package manager?

Package managers or old school download from a website (gnu) provide a separate public checksum and GPG signature in multiple mirrored locations. Even if their server was compromised I can still be safe.

If you're aware of the above then you're aware of what you're doing by piping curl into bash.

In reality, nobody checks checksums of binaries they download, so piping curl into bash makes no difference.

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

#934

Post by verdverm »

morshu9001 wrote: post #542
verdverm wrote: post #11

I'd put type annotations and GIL removal above UV without a second thought. UV is still young and I hit some of those growing pains. While it is very nice, I'm not going to put it up there with sliced bread, it's just another package manager among many

I don't want type annotations. Was kinda the point of Python not to deal with types.

One problem is when people store different types in the same variable, what type is it at the time I use it.

Types save you cognitive effort and catch errors earlier, while writing code, not later when running or testing

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

#935

Post by forrestthewoods »

dirkc wrote: post #825
forrestthewoods wrote: post #332

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 t…

Does uv use a sandbox or do process isolation? I've switched to running any and all python projects in Docker as a way to ensure that low effort supply chain attacks doesn't easily get everything in my home dir. So even if I use uv, I'd only do that in a Docker image for now

No idea. Probably not?

Docker images are a productivity killer. I don’t want to waste even 1 second building an image. And all the hoops you have to jump through to enable rapid iteration aren’t worth it.

Docker Images are fine - I guess - for deployment. But for development I absolutely hate them.

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

#936

Post by kristjansson »

Uehreka wrote: post #677
BrenBarn wrote: post #659

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it w…

> I don’t want a thing that hijacks my terminal and PATH

The shame is ... it never had to be that way. A venv is just a directory with a pyvenv.cfg, symlinks to an interpreter in bin, and a site-packages directory in lib. Running anything with venv/bin/python _is_ running in the virtual environment. Pip operations in the venv are just venv/bin/python -m pip ... . All the source/deactivate/shell nonsense obfuscating that reality did a disservice to a generation of python programmers.

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

#937

Post by kristjansson »

globular-toast wrote: post #925
nickelpro wrote: post #920

Earlier quoted context omitted.

This is a key tenets of venvs generally, uv didn't invent anything, it simply brought them under one roof and improved perf.

It should have been, but people definitely kept their venvs as pets or, worse, just used the global env.

It was way too easy for the venv to be the only artifact of the process used to produce it. pip install, hit a bug, install some other dep, another bug, oh this one needs to be downgraded, and so on until it works. Without more effort to memorialize / remember the steps, deleting the venv destroyed the work to create it.

uv, in addition to its raw speed, is very clever to record things in pyproject as the user interacts with it.

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

#938

Post by isodev »

collinmanderson wrote: post #909
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.

Does the conda package manager have the same issue?

conda and pip are compatible, you can build a conda project with pip

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

#939

Post by neves »

prpl wrote: post #495
gostsamo wrote: post #79

Earlier quoted context omitted.

As far as I get it, conda is still around because uv is focused on python while conda handles things written in other languages. Unless uv gets much more universal than expected, conda is here to stay.

conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything. Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.

Conda is hell for multi operationg systems projects. Its lock file is OS dependent. You can't commit it and hope it will work anywere.

It is probably the easiest way to install a lot of binary dependencies, good for who doesn't have experience with sofware development and don't care with reproductbility.

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

#940

Post by miki123211 »

thayne wrote: post #657
miki123211 wrote: post #643

Earlier quoted context omitted.

I wish we had a language that had the syntax of Python (notably including operator overloading, which is absolutely critical for neural networks, ML, data science and numerical computations), the performance, compile times and concurrency support of Go, the type system flexibility of Typescript, and the native platform integration of C/C++.

Rust doesn't quite hit all of those, but it hits a lot of them. It's syntax is significantly different from python, but it does have operator overloading. It's performance is comparable to go, and has good concurrency support, although it is different than go, and there are still some rough edges with "async" code. Compile times aren't as good as go though. The type system is excellent, although I'm not really sure w…

Among other things, a flexible type system is one where you can write a function that takes objects with keys in snake_case, and then (recursively) converts them into camelCase. In Typescript, you can make such a function generic, and it'll all type check. Your code editor will even offer autocomplete for the camelCase keys, even though the only explicit type definition is camel_case.
Post reply on HN