bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[zimoun]

Hi Ludo,

On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès <address@hidden> 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