Hi Hugo, >> In the first case, Guix imposes very few constraints on what you can >> package. Make your own channel, add what you like, and publish it. > > That was my original plan, but the Guix manual explicitly suggests to > consider the main channel first; it is much more fun collectively.
There are collective add-on channels as well, e.g. guix-past and guix-science. > Plus, if everyone publishes on their own channel, then we reintroduce > the problem of "finding a set of packages that works well together", but > with channels instead of individual packages. That's the real issue I see. >> I'd love to see a convivial Guix variant that contains fewer packages >> carefully selected for stability. On top of that variant, we could have >> channels with various policies, including multiple channels for Python >> software, some going for bleeding-edge and others for occasional >> snapshots of the ecosystem that remain usable for years. With the >> current main channel, this is very hard to achieve because Python is >> already part of it. > > Why can't we do what you just described directly on the main channel? Because one channel can have only one policy. The main channel has the policy of tracking upstream changes as quickly as possible, so it transmits the anti-conviviality properties of the Python ecosystem to Guix users. > That is, a basic but stable core e.g. just the basic Python versions and > some build tools. And different sets of Python packages on top of that. Would that work if you end up having more than one Python version in a profile or shell? If it does, yes, that would be a possible approach. Much like we have multiple versions of gcc. Package naming would be a mess, however, because the Python version for each package would have to be encoded in its name. > With conda and PyPI you only need a lock file. (I know why that is > horrible, and not enough, that is why I'm here.) With conda, a lock file remains usable for about 6 months on average. PyPI should be better in theory, but I have no experience in practice. Pixi is supposed to be better than conda in this respect, while using conda package definitions, but I haven't tried it yet. > I don't know. The maximalist approach seems to be prevailing; we add > packages faster than we can maintain them. Indeed! > So I would expect a system that reduces artificially engineered > obsolescence resulting in more working packages would be welcomed. I hope you are right! Cheers, Konrad.
