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

[zimoun]

Hi Konrad,

On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen <address@hidden> wrote:
>
> Hi Simon,
>
> > Maybe I miss a point. It is not: "watch out, this will do something
> > else in the future" but "watch out, this was doing something else in
> > the past and the change happened the <date> in <commit>".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a few months. What am I supposed to do about this?

Assuming "guix environment" would stay and following the proposed
plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top
of your script. In this would not be a problem for travelling back in
time.


> > First, I am not convinced that there is not so much scripts that will
> > be broken. And second, I am not convinced neither that these very
> > scripts need time-traveling.
>
> Perhaps it's just me, but I use "guix environment" quite a lot in
> scripts, in order to make them more reproducible. Here's a simple
> example:
>
>    #!/usr/bin/env bash
>    guix environment --container --ad-hoc gcc-toolchain <<EOF
>    gcc pi.c -o pi
>    ./pi
>    EOF

With the proposed plan, this would stay the same. Even, the --ad-hoc
option could stay forever for backward compatibility.

The only issue is for example:

    #!/usr/bin/env bash
    guix environment --container gmsh <<EOF
    mkdir build
    cd build
    cmake ..
    make
    ./bin/gmsh
    EOF

And I not convinced that this kind of scripts need to be robust for
time-travelling, I mean it is easy to correct adding the --inputs-of
option or set the GUIX_ENVIRONMENT_DEPRECATED variable.


> > Yes, it is probably the most adequate to do. But it is sad to loose
> > the good name "guix environment"... and we know that naming is hard.
> > ;-)
>
> I definitely agree. As a lesson for the future, maybe we should use
> not-so-nice names for new commands during a kind of beta-testing phase.

What do you think about "guix shell" for the new "guix environment" behaviour?

What the others think?
New name (easier) vs transitional plan (trickier)?
And new names proposal:
  -  guix env
  -  guix shell
?


All the best,
simon