On 7/16/26 13:44, Andreas Enge wrote:
Am Thu, Jul 16, 2026 at 12:28:15PM +0200 schrieb Hugo Buddelmeijer:
Instead, we would do better by allowing sage to use libraries A' and B' that
propagate the same version of C. Maybe the versions of those libraries are
specifically kept for sage.
Well, that looks like a combinatorial explosion of library versions
depending themselves on all kinds of combinations of other library
versions. Who is going to maintain the A' and B' libraries?
A' with C_1, D_1, ..., Z_1 as input,
A'' with C_2, D_1, ..., Z_1 as input,
and 2^24-2 other variants. You get the idea...
No no, not at all!
Yes, ultimately those unmaintained packages could lead to such an
explosion. So to prevent that, we would decide to patch them, or remove
them. But we won't patch packages because they are broken, causing
churn for us. We'd patch them because those patches solve a problem for us.
Currently, the unending relentless patching *is* the problem.
Will we not end up with something like a "docker image" for sage,
with a bespoke Python library graph for every Python application?
Only for a select few applications we would end up with a "guix shell"
per application. But that would be because those apps are deemed to
good to remove and too complicated to patch, so we would be making use
of Guix strengths.
However, most old packages work fine together with other old packages,
so we probably only need a handful of combinations.
For example, we could start with providing all currently supported
Python versions. I think that would be a good idea anyway, even without
packages. That would be 3.10 to 3.14.
We deem one of them 'the current' Python, say 3.12, and almost all
packages have a variant that works with that. Our main activity would
be filling up the 3.13 set, with some brave souls already already
working on 3.14 support. We'd do that mainly by waiting for upstream to
release new packages, not by patching.
We'd still also refresh the packages for 3.12 and 3.11 (and 3.10),
automatically even, because most packages will just be variants of each
other created through a transformation or otherwise inheritance.
At some point we get versions of libraries that we decide to only
package for 3.13 (e.g. Pandas 3, NumPy 2.4) because bringing them to
3.12 would cause too much hassle. (Probably not due to the Python
version an sich, but due to other packages that have a, ehm, slower
maintenance cycle, and only work with the older library versions).
Then at some point (~once a year, no strict schedule necessary) we shift
everything, and make the Python 3.13 set the default, add Python 3.15,
and mainly work on Python 3.14. The packages in the Python 3.12 set
become the 'legacy' set.
We would then move the rest of Guix to that default, e.g. Rust and Gnome
(but maybe those even lag a bit more, that's fine too).
At that point we would also drop Python 3.10, and just drop all the
packages that are only available there, because people would have had 4
years to do something else with those packages. That's fine, because
there is always guix time-machine. Some of those packages might be
retained, working only in their own little "guix shell", that is also fine.
That way we make use of the strengths of guix:
- We only have to patch for guix-specific things.
- We have new, bleeding edge packages.
- We have old, rock solid packages.
- We have a relaxed pace.
The current 'everything must work together' forces people to do a crazy
amount of work to patch packages faster than their own authors care to
maintain them.
Because currently, if you want to add a package that needs a new version
of a library, e.g. Pandas 3, then you don't just need to refresh Pandas
(that work is expected), but you also need to patch the hundreds of
existing packages that only work with an older version of that library
(that work should be totally unnecessary).
I'll work towards making this a technical possibility (well it is
possible, just very hard), and then we can take it from there.
