Hi Konrad et al.,
On 16/7/26 21:44, Konrad Hinsen wrote:
Hi Hugo,
Thanks for your kind words about my blog post!
Thank you for making the effort to write it.
In my opinion, that depends on how you look at Guix, and what you
consider an essential part of Guix. In particular: Is your Guix the
package manager, the collection of packages in the main Guix channel, or
the full system distribution?
I consider Guix all three, but here I was referring to the collection of
packages, and in particular the 24000 packages depending on Python. The
way we package Python currently is very non-convivial (insofar I
currently understand that concept).
In particular there is endless churn to prevent obsolescence. It
doesn't have to be that way, we can do better.
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.
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.
In the second and third cases, the problem is that the Guix package
collection, i.e. the main channel, includes highly non-convivial
ecosystems, such as Python. They have become dependencies, and that
means that the Guix channel can never be convivial.
I'm not that nihilistic (yet?), but it seems we are in agreement that
the (Python) packaging part of Guix is currently not convivial and that
that is bad.
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?
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.
That would be very similar to what I suggested, and if we could pull
it off, then I would prefer that over separate channels.
As Simon explained, PyPI and conda merely make it easier to add
packages. For a convivial package system, that's not sufficient. In
particular, both PyPI and conda make it very hard for users to compose
the package versions of their choice.
Maybe we are talking about different things, because in my experience it
is very hard to do anything with Python that is not on the 'happy path'
of Guix.
We have the technological basis to compose package versions in a way
that in theory can be better than conda and PyPI. But in practice, I
don't think it is better at the moment.
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 Guix you already need 67 lines just to select a different Python
version (assuming that version is already packaged):
https://codeberg.org/guix/guix/issues/9250#issuecomment-17537411
We can make the situation better though; I'll make reducing those 67
lines my next Guix-goal (after I'll finally package my own software that
needs Python 3.12).
What is the problem we set out to solve? Maybe we should start by
defining it more clearly, and see if we actually agree on a common
definition as a community. I suspect that we don't.
Here I was specifically referring to the conviviality problem of the
Python ecosystem. That is the most imminent problem I'm trying to solve
with Guix. There are more problems we set out to solve though.
But I did not have the correct words until recently, so even past me and
current me would not agree on a common problem definition :-). And I
need to read more about conviviality to understand it properly, so
future me will probably have yet another problem to solve.
(With respect to solutions, past me, like a month ago, suggested to use
LLMs, because I didn't understand the problem, so who knows what future
me would suggest.)
How exactly we should revive conviviality w.r.t. what we package would
be a collective exploration. If any operating system can do it, it is
us, because all the groundwork is there to keep old packages around.
Yes, we could do that. But my feeling is that this is not the vision of
most of the Guix community.
I don't know. The maximalist approach seems to be prevailing; we add
packages faster than we can maintain them. So I would expect a system
that reduces artificially engineered obsolescence resulting in more
working packages would be welcomed.
