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

From: EuAndreh <[email-masked]>
Date: Mon, 30 Dec 2019 06:44:34 -0300

Hello :)

Jumping in the discussion xD

Ludovic Courtès <[email-masked]> 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.