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

901–910 of 1001 posts

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

#901

Post by the__alchemist »

oofbey wrote: post #391
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…

Have you found it easy to write rust modules with python interfaces? What tools do you recommend?

PyO3 + Maturn is fine, but it's a bit tedious if you have a big API. Some annoyances:

  - Enums with inner types require hacks
  - No clean way to make your Rust enums into Python enums
  - More boilerplate than you should have. I think I will have to write my own macros/helpers to solve. For example, you need getters and setters for each field. And the gotcha: You can't just macro them due to a PyO3 restriction.
  - No way to use other Python-exposed rust libs as dependencies directly. You have to re-expose everything. So, if your rust B lib depends on rust A, you will make a PyO3 Rust A package, but instead of re-using that in PyO3 Rust B, you will copy+paste your PyO3 Rust A boilerplate into PyO3 Rust B.
If you're maintaining a single lib and want to expose it to Python, it's fine once you find a pattern that works. If you have a network and/or your API is large or not stable, it's a mess. (but doable)

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

#902

Post by blactuary »

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 is me exactly. I have a default dev environment, and a couple for experimenting with new versions of various packages, I don't need or want "projects" most of the time

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

#903

Post by bunderbunder »

jelder wrote: post #899

> On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers. Does that mean they aren't running unit tests _at all_ in CI yet, or they just use a totally different, newer system in production than they do for CI? Either way, brave of them to admit that in public.

My team just did this.

It wasn't anything like the radical change to how CI works that you seem to be envisioning. It was just deleting a lot of Python environment setup and management code that has a history of being obnoxious to maintain, and replacing it with a one-liner that, at least thus far, has given us zero fuss.

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

#904

Post by neves »

hexbin010 wrote: post #840

I predict it'll be the best and then the 'worst' thing: they'll go hard on monetisation. Just look at this post: 1839 points and 1048 comments! That is insane. It's captured the hearts and minds of Python devs and I'm sure they know it. I'm not against projects making money, just remember you'll likely pay a price later on once you invest in more of Astral's ecosystem. It's just temporarily free.

The Python Software Foundation includes highly competent contributors. One reason I adopted uv is confidence in the Python community’s engineering decision to prevent the take over of the platform.

Progress is already underway. PEP 751 proposes a standardized format for lock files: https://peps.python.org/pep-0751/ This helps to reduce tool-specific lock-in.

uv is open source, so forking remains viable. Build metadata is committed, and conversion to other tools is feasible if needed.

However, we must all remain vigilant against the risk of lock-in.

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

#905

Post by gaindustries »

lijok wrote: post #888
motbus3 wrote: post #883

Earlier quoted context omitted.

Until they change their minds. If they were serious about it, it would be part of PyCQA

The same PyCQA that they worked hard to do a significantly better job than?

[dead]

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

#906

Post by prpl »

the__alchemist wrote: post #895
prpl wrote: post #495

Earlier quoted context omitted.

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.

You can do all of the above with Wheels.

Can you show me someone who has packaged log4cxx in a wheel? Is it in pip?

Arbitrary examples, I know, but I moved a large software that was truly mixed C++ and python project to conda-forge and all sorts of random C++ dependencies were in there, which drastically simplified distribution and drastically reduced compile time.

If I had done it today, it might be nix+bazel, or maybe conda+bazel, but maintaining a world of C++ libraries for distribution as wheels does not sound like fun - especially because nobody is doing that work as a community now

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

#907

Post by blactuary »

BrenBarn wrote: post #669
tlarkworthy wrote: post #666

Earlier quoted context omitted.

It unblocks that workflow, that's why it's so great. You can have a single script with inline dependencies that are auto installed on execution. That can expand to importing other files, but there is very little setup tax to get started with a script and it does not block expansion.

It's not about single-file scripts, it's about having a "sandbox" environment in which various things can be messed with before abstracting anything out into a project.

This is a divide among different Python devs it seems. A lot of people are running scripts, which I will do eventually, but I spend a ton of time in a REPL experimenting and testing.

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

#908

Post by zbentley »

pidgeon_lover wrote: post #890

> Can install any version of Python Does "any" version include custom homebrew builds of Python, e.g. backports of Python 3.12 to Windows Vista/7?

No, uv installs pythons available from https://github.com/astral-sh/python-build-standalone by default, which are quite good and have a wide variety of versions available, even on unusual platforms. If those don’t suit your needs, uv can be configured to use (and in some cases install or download, though that gets hairy) other versions you have installed yourself: https://docs.astral.sh/uv/concepts/python-versions/#managed-...

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

#909

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.

Does the conda package manager have the same issue?

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

#910

Post by arcanemachiner »

ModernMech wrote: post #893
darkamaul wrote: post #770

Earlier quoted context omitted.

I think better developer tools tend to compound over time, they raise expectations and push the whole ecosystem forward. IMO, uv is quickly becoming one of the best reasons to start a new project in Python. It’s fast, and brings a level of polish and performance that makes Python feel modern again.

I think uv is one of the best examples of why not to start a new project in Python. I mean, depending on the project really, Python has its place. But if your project is anything like uv, uv proves you can't actually write an app like uv in Python. So for as great as uv is, its proximity to Python is a constant reminder of its shortcomings.

A car doesn't move as fast as an airplane can.

Therefore, cars are useless and nobody should use one.

Post reply on HN