Now though? It's way easier to have a herd of unicorn docker containers running that each handle one weird thing in isolation.
(At the end of the day, this is exactly what support tiers are for. CPython, at least to my eyes, has been very transparent about not guaranteeing support for every platform that has a C compiler.)
woodruffw•52m ago
(I am one of uv’s maintainers.)
The nice thing about Python packaging is that it’s standardized: if uv’s build backend doesn’t fit into the hole you want, then you can use any number of other backends that do an admirable job of conforming to the packaging standards.
With that said, I don’t understand why Gentoo needs to rebuild every single release of uv-build. It doesn’t change as much as uv itself, and it’s intentionally compatible across uv versions. Why not set a policy of only updating once weekly, or even less frequently, with exceptions for important breaking changes or bug fixes?
(For context: the only reason uv-build releases as often as it does is because it’s easier to keep its internals in lockstep with the rest of uv. But you can do a normal version bound in your Python build backend metadata and uv will happily use whatever version of uv-build is already present.)
ForHackernews•51m ago
r_lee•45m ago
collinfunk•44m ago
pjmlp•21m ago
tfrancisl•2m ago
p_l•33m ago
Admittedly rustification like that is a problem not only for gentoo, I have commercially deployed systems where one of the most annoyings elements of updating is presence of rust in python deps...
woodruffw•30m ago
(This is the default when you initialize a project with uv, so I think someone would need to go out of their way to configure their build backend to request a specific patch version of uv-build.)
pdonis•5m ago
This wouldn't necessarily solve Gentoo's problem. The only way to be sure to solve Gentoo's problem would be for every Python project that uses uv-build to specify one particular version. Then Gentoo could be sure that once that release of that project was built once, it would never change.
In other words, for a distro like Gentoo, the build backend is a dependency, and if it changes, that triggers a change in the build, even if the build backend change would not actually change the final wheel that got built.
arto•27m ago
crabbone•15m ago
No. Python packaging isn't standardized. Tools aren't interchangeable. And they are all bad, uv including. I wish it didn't exist, so that there were fewer problems for people like me, whose job is, essentially, working around the problems created by people who build tools like uv and people who mindlessly adopt them.
To answer to your specific arguments: nobody is going to believe that your proposed solution is going to hold water longer than it takes for milk to go sour. Too many people, too often had burned on Python packaging tools to trust some tool not to break, to be consistent etc. Without even realizing it, you suggested that someone else should use a crutch to work around the problem you created, and you expected them to just go along with the flow and live by the bottom of the barrel lowest possible "standards" that exist in Python packaging world. No wonder they don't want uv-build... why would any sensible person want it?
woodruffw•9m ago
(It’s not kind or charitable to call someone a liar.)
pdonis•10m ago
But it isn't. Once upon a time, it was: you used distutils. But of course distutils had a lot of problems. Instead of adopting a single standardized solution for those problems, the Python developers punted and let third parties do it. So now we do not have a single standardized solution for building Python packages; we have a bunch of third party solutions, none of which is in the Python standard library.
Yes, all those third party solutions have to be PEP 517 compatible, but that's not standardization on a tool; it's just standardization on an interface between the backend and the frontend. Which is nice, but doesn't solve the problem under discussion here.
> if uv’s build backend doesn’t fit into the hole you want, then you can use any number of other backends that do an admirable job of conforming to the packaging standards.
As the project developer, sure. But as a Linux distro building your python package, Gentoo has to use the build backend you specify. It can't say, well, this particular package is just pure python, so really all we need is a minimal tool to build a pure python none-any wheel. It has to use the backend you specified.
> I don’t understand why Gentoo needs to rebuild every single release of uv-build.
Because if you don't pin a version of uv-build in your project, that means "use the latest version available". Gentoo can't second guess you--even if it were able to verify somehow that the new version of uv-build that just got released will end up producing an identical wheel for your project as the previous version, without actually using the new version of uv-build.
> you can do a normal version bound in your Python build backend metadata
Sure, but how many users of uv-build actually do that? Seems like the answer to that is "not enough to matter".
woodruffw•4m ago
At the end of the day, it’s hard for me to even pinpoint what is problematic for Gentoo here: I can understand that they need to support multiple build backends as a reality of Python packaging and that’s frustrating, but per below it seems extremely unlikely that they actually need to build every single patch version of uv. Nothing about uv’s defaults or the packaging template would require that, and users would have to go out of their way to configure their build backend in that way.
(And note: this is not unique to uv! You can grief anybody who does an sdist build by pinning to a random ancient version of setuptools or any other build backend, including other ones that use native code. This is why uv, like everybody else, encourages semver ranges for build backends.)