Hello :) Jumping in the discussion xD Ludovic Courtès writes: > Yes, I think it is clear that we’d have to do this using all the tools > at our disposal, including time. > > Konrad’s objection remains though: existing documents (papers, blog > posts, MOOCs, etc.) that mention ‘guix environment’ would all of a > sudden become wrong if we were to change the defaults of ‘guix > environment’. Even if we introduce a variable to restore the old > behavior. > > Perhaps that’s unavoidable in the long run, but perhaps this is not the > right time for this. Wouldn't having a new name for the new behaviour avoid breakage in this situation? Suppose the path of adding new subcommand is chosen, and it is "guix shell". Couldn't it adopt the new desired behaviour? guix shell foo --inputs-of bar # new command guix environment bar --ad-hoc foo # untouched old command After the introduction of "guix shell", "guix environment" could become deprecated, but no current usage of it would stop working, and no public references to it in the internet would become misleading. "guix environment" could say that is has been deprecated, and point to "guix shell", but keep working the same way. If desired, "guix environment" could be removed after X time of deprecation has passed, but that would be optional. What are the downsides? Am I missing something? Thanks, euandreh.