On 7/15/26 19:42, Andreas Enge wrote:
Am Tue, Jul 14, 2026 at 02:46:58PM +0200 schrieb Hugo Buddelmeijer via
Development of GNU Guix and the GNU System distribution.:
In fact, we are doing *worse* than other ecosystems. Half of Konrad's
article is about the poor state of the Python world. Yet adding packages to
PyPI or conda feels far more convivial than adding them to Guix!
I do not really know, but do these two also make sure that the latest
additions all work harmoniously together?
The realization from Konrad's post is that our current approach to
achieve harmony for Python packages is exactly how we should *not* do
it. It breaks conviviality and it causes enormous churn.
My take-home from Konrad's article: having one package be more 'modern'
and 'better' than another, by no means imply that the other package is
'broken' and needs to be 'fixed' in the name of progress or harmony.
Luckily, Guix by design makes it feasible, desirable even, to have all
these different packages to co-exist harmoniously all the while being
incompatible.
Yet almost all the time spent within our Python ecosystem is 'fixing'
'broken' old software (or worse, deprecating it) so we are able to
package new 'modern' packages.
That is, it is currently only possible to add new Python packages by
spending hundreds of hours on this churn of fixing 'broken' packages.
And it never stops. As a result, only extremely dedicated people like
Oleg and Nicolas (can) maintain our Python packages, which is
unsustainable long term.
A side-effect of all this 'fixing' is that our Python packages are full
of patches and substitutes. About 30%, the most of all ecosystems.
Those fixes alone make these packages hard to maintain, because they
can't easily be `guix refresh`ed.
The solution is to stop forcibly 'fixing' old packages, because they are
not 'broken' to begin with. And Guix makes this easy.
I propose the following. To first order:
10) We package Python packages 'as they are', including the needed
dependencies.
11) We patch/substitute only what is specifically required for Guix,
e.g. for reproducibility, for off-line building, unbundling
dependencies, etc.
Then we make use of the excellent features of Guix:
20) If incompatible packages require packaging multiple versions of
Python, or multiple versions of core libraries (e.g. NumPy), then so be
it (to first order).
21) We make it easy to mix and match those version through
transformations. This mix-and-matching is essential for Python because
it relies so much on propagated inputs, and we cannot know in advance
all the combinations people might want. Unfortunately, this is
currently extremely hard for Python itself, see
https://codeberg.org/guix/guix/pulls/9324
22) We offer (substitutes for) a limited set of combinations. I suggest
two: a default set where most packages work and a 'future' one, that
will have packages missing. The future set will at some point become
the default one.
23) On top of those general combinations, we provide
application-specific subsets. E.g. if a specific game requires some
outdated libraries, then we provide them specifically for that game.
Then we are essentially done:
- People can use very old packages that are incompatible with newer
packages, and
- those old package won't restrict adding newer packages.
Nevertheless, we still might want to occasionally patch packages for
compatibility reasons. But the point is that we should only make such
patches because we want to, as an optional activity (at the moment this
compatibility-patching is where most of the time is spent). E.g.:
30) Upstream often has very strict 'locks' on dependencies out of
precaution. But those packages often work fine with newer packages
anyway, in which case we can just patch that.
31) If only a handful of packages require an older dependency, then we
might deem it less work to patch those packages and remove the older
dependency than to keep it around.
32) If there is a security issues with an older library, and upstream is
not responsive, then we might decide to patch packages to use a newer
library ourselves.
I'll take steps towards the above; starting with making it easier to
choose Python versions through https://codeberg.org/guix/guix/pulls/9324
Thanks for coming to my TED talk.
Hugo
