Hi Mark, Mark H Weaver <m...@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’.
