Hacker News Reader

Comment by pdonis | Hacker News Reader

> It’s the obvious way to implement backend resolution.

If a compatible version is already present, yes, a frontend can just use it if it's within the semver range specified.

But in many cases, builds are done in a fresh virtual environment that has nothing installed. In such a case, the only option is to download the latest version that's in the semver range specified. That's how the "build" frontend works, for example, unless you specify a flag to keep it from creating a fresh virtual environment.

View on HN

Is that what Gentoo is doing here? I thought the whole point of the distro doing any sort of Python packaging is that they can pierce abstractions like virtual environments where it suits them.

(But also: if we’re talking virtual environments then we’re firmly in Python land, not distro land, where the correct answer is “use a wheel” instead of building it yourself.)

The whole point of Gentoo is to build everything directly from source. That means doing whatever the build source tells you to do. It also means not using a pre-built wheel, since that's not source code.

From what I can gather, Gentoo's Python build system does use a virtualenv [1]. Maybe that's not your definition of "distro land", but it appears to be Gentoo's.

It's not clear to me exactly what frontend build tool is used, whether it's one of the well known ones or something that the Gentoo developers coded themselves. However, if it's using a virtualenv, it's going to have to re-fetch the build backend and rebuild it.

[1] https://projects.gentoo.org/python/guide/basic.html

If it’s using a virtual environment, then they can pierce the abstraction by inheriting system packages, including a compatible uv-build. There’s nothing about Python packaging that requires them to rebuild the backend multiple times.

> If it’s using a virtual environment, then they can pierce the abstraction by inheriting system packages

Which defeats the purpose of doing the build in a virtualenv, which is to avoid any possible collision with or contamination by other stuff that's installed on the system by using a fresh copy of everything.

They’re already defeating the point of Python packaging in multifarious ways here. The entire reason uv and uv-build exist is because we have mature, smooth mechanisms for not rebuilding the world.

uv and uv-build are not equivalent to "Python packaging". Perhaps you would like them to be, but they're not.

I don’t know what “equivalent to” would mean here.

Speaking as someone who has written many Python packaging PEPs and who has maintained (and continues to maintain) PyPA tooling that you almost certainly use: uv and uv-build are as much a part of Python packaging as anything else that interfaces with the standards.

Reply on news.ycombinator.com