Live data from Hacker News

Uv 0.3 – Unified Python packaging

astral.sh

41–50 of 60 posts

Re: Uv 0.3 – Unified Python packaging

#41

Love that you’ve kept the workspace support from Rye. Is there any support for workspace _builds_? That is, resolving the graph of interdependencies between packages to build a wheel/Dockerfile/whatever? Fwiw I’m building a thing [1] that does this. Current docs suggest Rye but will s/rye/uv/ shortly. It’s basically just some CLI commands and a Hatch/PDM plugin that injects needed stuff at build-time. [1] https://una…

Just did some playing around and workspace support has definitely evolved from Rye [0] but there isn't yet (afaict) any mechanism that supports building workspace packages with their "internal" dependencies.

[1] https://docs.astral.sh/uv/concepts/workspaces/

Re: Uv 0.3 – Unified Python packaging

#42
Ok so stupid question.. even though the majority of package documentation seems to mention pip, it's very dated, right? And I have only been trying to focus a bit more on python the last couple of years, so actually I just found out about poetry like last month. But poetry is also very uncool now right?

Most people not on the bleeding edge use conda, not poetry? But people who are hip use rye and uv? Up until today and now they only use uv if possible?

I'm actually building a system around user-installed plugins. Where there is a UI to search for and install plugins on the fly.

Also one other thing just to double check, it is now very uncool or considered bad practice to use dynamic or flexible types in Python?

Re: Uv 0.3 – Unified Python packaging

#43
post #42

Ok so stupid question.. even though the majority of package documentation seems to mention pip, it's very dated, right? And I have only been trying to focus a bit more on python the last couple of years, so actually I just found out about poetry like last month. But poetry is also very uncool now right? Most people not on the bleeding edge use conda, not poetry? But people who are hip use rye and uv? Up until today a…

Conda is mainly used by ML, AI, and data science people and to a certain extent feels like its own separate ecosystem. In other areas, like web dev, conda use is pretty rare.

Re: Uv 0.3 – Unified Python packaging

#44
post #43
post #42

Ok so stupid question.. even though the majority of package documentation seems to mention pip, it's very dated, right? And I have only been trying to focus a bit more on python the last couple of years, so actually I just found out about poetry like last month. But poetry is also very uncool now right? Most people not on the bleeding edge use conda, not poetry? But people who are hip use rye and uv? Up until today a…

Conda is mainly used by ML, AI, and data science people and to a certain extent feels like its own separate ecosystem. In other areas, like web dev, conda use is pretty rare.

Ok so for web dev, are most projects using poetry, the, or something else?

Re: Uv 0.3 – Unified Python packaging

#45
post #42

Ok so stupid question.. even though the majority of package documentation seems to mention pip, it's very dated, right? And I have only been trying to focus a bit more on python the last couple of years, so actually I just found out about poetry like last month. But poetry is also very uncool now right? Most people not on the bleeding edge use conda, not poetry? But people who are hip use rye and uv? Up until today a…

[deleted]

Re: Uv 0.3 – Unified Python packaging

#46
post #20

Does it support building native extensions and Cython modules or are setuptools still the only reasonable way to do this?

Uv is installer not a build backend. It’s similar to pip. If you install library with uv it will call backend like setuptools as needed. It is not a replacement for setuptools.

Re: Uv 0.3 – Unified Python packaging

#47
post #44
post #43

Earlier quoted context omitted.

Conda is mainly used by ML, AI, and data science people and to a certain extent feels like its own separate ecosystem. In other areas, like web dev, conda use is pretty rare.

Ok so for web dev, are most projects using poetry, the, or something else?

Most projects do just fine with pip + venv, and that’s what they stick to.

The exception is if they have specific dependencies outside the CPython ecosystem - in which case they’ll probably be using conda. Examples of such dependencies include nodejs/cuda/cublas/specific versions of gcc. Webdev generally doesn’t have as many of these dependencies compared to the data world, which is why conda is less popular there.

Speaking in sweeping generalities here: you probably don’t need poetry, uv, or kin - at all. But there’s nothing wrong with choosing to use them if you prefer to do so either.

Re: Uv 0.3 – Unified Python packaging

#48
post #47
post #44

Earlier quoted context omitted.

Ok so for web dev, are most projects using poetry, the, or something else?

Most projects do just fine with pip + venv, and that’s what they stick to. The exception is if they have specific dependencies outside the CPython ecosystem - in which case they’ll probably be using conda. Examples of such dependencies include nodejs/cuda/cublas/specific versions of gcc. Webdev generally doesn’t have as many of these dependencies compared to the data world, which is why conda is less popular there. S…

ok.. thanks.. but the reaction in this thread seems to slightly contradict that? I didn't see anyone say "we use pip + venv, it works fine".

Re: Uv 0.3 – Unified Python packaging

#49
post #48
post #47

Earlier quoted context omitted.

Most projects do just fine with pip + venv, and that’s what they stick to. The exception is if they have specific dependencies outside the CPython ecosystem - in which case they’ll probably be using conda. Examples of such dependencies include nodejs/cuda/cublas/specific versions of gcc. Webdev generally doesn’t have as many of these dependencies compared to the data world, which is why conda is less popular there. S…

ok.. thanks.. but the reaction in this thread seems to slightly contradict that? I didn't see anyone say "we use pip + venv, it works fine".

Think of it this way: the release of VS Code didn’t mean people suddenly stopped using or updating Emacs/Vim. VS Code simply offered a more polished, beginner-friendly way of setting up and building software projects than the old TUI editors.

In the same way, none of the “fancy-pip-replacement” projects will outright obsolete pip or conda. They’re just tools that can work a bit more intuitively for new users and provide a bit of polish/UX value - but their niche fills the exact same role as pip/conda: managing the set of binaries on your PATH.

Post reply on HN