bug#22629: Channels!

[ludo@gnu.org (Ludovic Courtès)]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> I'd like to say again that I have grave concerns that this could be the
> death-knell for long-term innovation in Guix.  It's likely that whenever
> a change is proposed that will break these third-party channels, there
> will be resistance, and efforts to preserve backward compatibility.

It is a risk and I acknowledge that.

In the 4 years of existence of GUIX_PACKAGE_PATH, we’ve never
encountered this issue.  To what extent would that change?  I don’t know.

I want to preserve the existing incentives to work in Guix proper, or to
work closely with the project when integration in Guix proper makes
little sense—for WIP packages, custom package variants, or
domain-specific packages like those I mentioned in my message.  I do not
see ourselves advertising channels as the primary way to add packages.

BTW, Andy’s Potluck offered a solution to the compatibility issue that’s
still on the table: <https://bugs.gnu.org/26645>.

> I fear that with the introduction of channels, that potential will be
> drastically curtailed, and that we're essentially trading our future
> potential for what will in practice, most likely, be primarily used to
> facilitate the use of non-free software on Guix.

Non-free software will be one use case.  There are other use cases
though, as mentioned above; these are the ones I’m interested in.

It’s a dilemma.  I’d like to think that we can have our cake and eat it
too; that we can give users this flexibility (which is “built in” since
it’s just a matter of setting the load path) without jeopardizing
development of Guix itself, and without creating the conditions for the
proliferation of non-free package channels.  Whether it works this way
would depend not on the technical details but on the group’s behavior.

Thoughts?

Thanks,
Ludo’.