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

[zimoun]

Hi Arne,

Thank you for the pointers.


On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide <address@hidden> wrote:

> Konrad Hinsen <address@hidden> writes:

> >> 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?
>
> This is the point where we need to ask ourselves:
>
>      Should Guix be volatile software?
>      http://stevelosh.com/blog/2012/04/volatile-software/

Guix is not a volatile software and will never be. Because it is
rooted in time-travelling.
The tools "guix pull --commit=", "guix <command> --manifest=", "guix
time-machine" or the "--roll-back" avoid to break what is currently
working.
Well, the section "The situation" just cannot(*) happen with Guix.
That's why Guix is awesome! ;-)

(*) well if one correctly uses Guix which is another story ;-)
and it is not perfect yet... see all the discussion about manifest. :-)


Now, let recall the formula (already discussed in this thread :-))

Number of people         Time it takes each person
using that part of   X   to figure out what changed
the program              and how to fix it

Hum? I am not convinced that the cost would be high... Because 1. the
number of people using Guix is not so high (yet!), so 2. I am almost
sure we can name the people using "guix environment" in scripts ;-).
And 3. the time to figure out what changed is really low -- especially
with warnings and hints -- and "guix environment foo -- make" would
return an error because of dependencies missing.

Other said, I do not see myself use-cases where the scripts using
"guix environment" need to be robust for time-travelling -- the same
script used with current, past and future Guix versions -- because as
it was said elsewhere: "environment" can be seen like "temporary
profile". And temporary means... well temporary. ;-)

Then, the section "The Tradeoff" advices "from newmodule import
new_foo as foo" and IMO it is what the plan proposes with the variable
GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).

Last, "volatile" vs "stable" is mitigated by "The future of 'guix
environment'" [1] which really predates the 1.0. ;-)

[1] https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html


As I said, I am not convinced by the argument: everything would be
broken, too much time to fix the break, etc. and this proposal would
lead to disaster for the end-user. But it is my opinion based on my
restricted personal experience.


> Also: Software developers should avoid traumatic changes
>       https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html

"Traumatic changes"? Maybe a bit extreme for the change we are talking about...



Well, at the end, what is explicitly your personal opinion?
 a. Change the behaviour of "guix environment" using the proposed plan?
or
 b. Add a new command? Which one? "guix shell", "guix env" or "guix
<you-name-it>"?


All the best,
simon