Hi Mark,
> 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. GUIX_PACKAGE_PATH already had that same problem (and did not provide a solution for it). With channels we can at least add more information about a collection of modules, e.g. what version of Guix it is known to work with. So channels really flesh out the feature provided by GUIX_PACKAGE_PATH, elevating it from a simple environment variable to one that can take additional context into account. I think that’s a worthwhile step to take. I agree with your sentiment that a mechanism based on a simple environment variable does not instill confidence, whereas a special mechanism like channels could signal to users that it’s a feature that provides some guarantees. But I disagree with your assertion that this would be “a death-knell to innovation”. That seems like an exaggeration to me. > My point is that I want to keep our APIs internal and unfrozen for the > same reason that Linux, the kernel project, does. Linux refuses to > support out-of-tree drivers and modules, and thereby retains its freedom > to change their internal APIs. Often they change how things work > internally and this entails doing massive find-replace on every driver > in the tree. This has been a crucially important factor in their > long-term success. […] > We should persue a similar model. The crucial thing is to always keep > the package modules together with the rest of Guix. I agree. That is and remains our recommendation. I still want most packages to end up in Guix proper. There are collections of packages for which this does not make sense, though, and I think that it is better to have a more formal mechanism that can also be used to describe the limits of compatibility than just a simple environment variable. I also agree with you that we don’t need channels for providing a stable branch. The biggest obstacle to providing a stable branch is not technical, but it requires people maintaining it. -- Ricardo
