IdeaWell

Project ideas from Hacker News discussions.

A plea not to use uv-build

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1: Gentoo’s source‑only model forces frequent rebuilds of uv‑build
Gentoo’s policy of building every package from source means that each new patch release of the uv‑build backend triggers a rebuild for every Python project that depends on it.

“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.” – woodruffw
“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… without actually using the new version of uv‑build.” – pdonis

Theme 2: Version‑constraint semantics in Python packaging could alleviate the problem
The discussion notes that uv (and most build frontends) default to semver ranges, so a compatible patch update should not require a rebuild unless a project pins an exact version.

“uv defaults to semver bounds, so a maintainer would have to go out of their way to introduce a troublesome backend constraint.” – woodruffw
“If you leave the build backend version unconstrained, the build frontend is allowed to resolve any version it sees fit, including the version it already has.” – pdonis
“If uv‑build goes from 0.13.1 to 0.13.2, then anybody with a semver bound of uv‑build>=0.12,<0.14 doesn’t need to update anything.” – woodruffw

Theme 3: Debate over Gentoo’s philosophy—source compilation vs. binary/customization
Commenters argue that Gentoo’s value lies in flexibility and control, not raw performance, and that the “compile‑everything” reputation is outdated.

“I doubt this oft‑repeated stereotype was every particularly accurate… Gentoo users are in it for control over their system and customization.” – bmenrigh
“Unfortunately, this perception of Gentoo remains, and I wish they would remove the verbiage from their site.” – simoncion
“For one thing you can, in theory, optimise for the CPU you have instead of some generic target that has to run acceptably everywhere.” – t43562

🚀 Project Ideas

Gentoo Binary Backend Cache (GBBC)

Summary

  • Provides pre‑built binary packages for Python build backends (uv‑build, setuptools, flit, etc.) for Gentoo’s supported architectures, eliminating the need to compile them from source on every update.
  • Core value proposition: saves CPU time and energy for Gentoo users by letting Portage fetch a binary instead of rebuilding the backend each patch release.

Details

Key Value
Target Audience Gentoo maintainers and power users who build Python packages from source
Core Feature Automated CI builds backend binaries and publishes them to a Gentoo‑compatible binhost (e.g., via emerge --getbinpkg)
Tech Stack GitHub Actions / GitLab CI, Docker for cross‑compilation, Gentoo ebuild repository, RSYNC/HTTP binhost
Difficulty Medium
Monetization Hobby

Notes

  • HN commenters expressed frustration: “If only there were ways to skip this waste…” (eviks) and noted Gentoo already has binhost capability but isn’t using it for backends.
  • Could spark discussion on extending Gentoo’s binhost policy to include build‑tool dependencies, reducing duplicate compilation across the community.

Build Backend Compatibility Checker (BBCC)

Summary

  • Analyzes two versions of a Python build backend to determine if they produce bit‑identical wheels for a set of representative projects, enabling Gentoo to decide whether a rebuild is truly necessary.
  • Core value proposition: prevents unnecessary rebuilds by providing a data‑driven compatibility signal that Portage can act on.

Details

Key Value
Target Audience Gentoo package maintainers, Portage developers, Python packaging tool authors
Core Feature Runs the backend in isolated environments, builds sample sdist/wheel pairs, compares hashes, outputs a compatibility flag
Tech Stack Python, uv/virtualenv, build frontend, hashlib, optional reproducibility frameworks like diffoscope
Difficulty High
Monetization Hobby

Notes

  • Commenters debated whether a new patch version truly changes output: “If uv‑build goes from 0.13.1 to 0.13.2… anybody with a semver bound … doesn’t need to update anything.” (woodruffw) – BBCC would make that provable.
  • Could be integrated into Portage as a pkg_pretest hook, generating valuable discussion on trust vs. verification in source‑based distros.

Shared Build Backend Cache (SBBC)

Summary

  • A peer‑to‑peer or central cache that stores compiled build backends keyed by version, architecture, and compiler flags, allowing Portage to reuse previously built binaries instead of recompiling.
  • Core value proposition: leverages existing work across Gentoo users (or CI farms) to cut down repetitive builds of the same backend.

Details

Key Value
Target Audience Gentoo users, Gentoo release engineering teams, CI/CD pipelines building Gentoo packages
Core Feature Content‑addressable store (like IPFS or a simple REST API) where a built backend is uploaded once and fetched by any system needing it
Tech Stack Rust or Go for daemon, SQLite/S3 backend, optional IPFS integration, Portage plugin (FEATURES="buildcache"), authentication via tokens
Difficulty Medium
Monetization Hobby

Notes

  • Users highlighted the waste: “…Gentoo users will spend many hours building new uv‑build versions over and over again.” (eviks) – SBBC directly addresses this.
  • Would encourage practical utility by showing how distros can adopt caching strategies similar to ccache but for build‑tool dependencies, fostering broader conversation about reducing source‑build redundancy.

Read Later