Hi Ludo, On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès <l...@gnu.org> wrote:
> > Wouldn't having a new name for the new behaviour avoid breakage in this > > situation? > > Yes, that’s correct (that’s also one of the suggestions Konrad made). Is this statement acted? Is it the consensus by all the maintainers? And I am not clear about what will happens for "guix environment"? Deprecate for sure. But after X time: removed or frozen? Removing the command "guix environment" is against the backward compatibility argument because all the current documentation/scripts using it will not work anymore. Other said, if the documentation/scripts cannot be updated as it was said -- in favor for strong backward compatibility -- then the user will be surprised that what worked does not anymore because the command does not exist anymore. Therefore, if Guix goes the backward compatibility route, then the "guix environment" should be frozen until the version 2.0 and so only removed when the 2.0 will be released. Or I misunderstand the arguments in favor of the backward compatibility. As Arne described the process (bottom of [1]), "guix environment" will become a kind-of alias of "guix shell/<name-it>". Right? > We could take that route. What would we call it, though? I don’t like > “guix shell” because it doesn’t quite reflect what the command is > about. No good idea, though. Argh! Naming is hard. Something that reflects what the command is about: "guix environment"? (joke!! ;-)) Why do you say that "guix shell" does not reflect what the command is about? Because the command spawns a new shell with options (expanding it, isolating it, etc.) Well, because we do not seem having good idea for a new name, maybe if we argument why we collectively find that name or this name is bad or good, one of us will find the good name. Currently, "guix shell" seems the better option. All the best, simon
