Hi Ludo, > Clearly there’s a tension between that and keeping Guix open to changes.
That's indeed the main problem and here as elsewhere, it is often a topic of heated arguments. My point of view (long form: https://hal.archives-ouvertes.fr/hal-02117588) is that software projects should adopt a backwards compatibility policy early on, state it clearly in their documentation, and stick to it. That prevents misunderstandings, bad surprises, and heated debates. As for what that policy should be for Guix, that's a more difficult story. For projects with versioned releases, I like the principles of semantic versioning, but Guix is more of a rolling-release project. (Test question: does anyone know what the current Guix version number is? Does anyone care?) I am not aware of any good precedents in terms of policy for such projects. > The hard question then becomes: what do we call it? I vote against > abbreviations. :-) > > Also, what other goals would we set for that command? How would we > frame it in the set of commands? I vote for discussing the second point before the first one. Names should reflect the functionality behind them. How about a unified command for constructing environments and profiles declaratively? In other words, combine "guix environment" and the declarative parts of "guix package". We could probably get rid of the somewhat obscure "guix environment -r" in the process. Cheers, Konrad.