GNU bug report logs - #38529
Make --pure the default for `guix environment'?

Previous Next

Full log

Message #68 received at 38529 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
Cc: Guix Devel <guix-devel <at> gnu.org>, 38529 <at> debbugs.gnu.org
Subject: Re: bug#38529: Make --ad-hoc the default for guix environment
 proposed deprecation mechanism
Date: Tue, 17 Dec 2019 18:07:45 +0100

Hi Konrad,

On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen <konrad.hinsen <at> fastmail.net> wrote:
>
> On 16/12/2019 23:09, Ludovic Courtès wrote:
> > So in a more algorithmic manner:
> >> 1. if ad-hoc and inputs-of is present at the same invocation: fail
> >> hard. (With an error like incompatible options present)
> >> 2. if only ad-hoc is present, then print a deprecation warning (yes,
> >> we could make this suspendable with an environment variable, like you
> >> described)
> >> 3. if only inputs-of present, then do the new behaviour.
> >> 4. if neither ad-hoc nor inputs-of present then
> >>    a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
> >>    b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
> >> new behaviour.
> > That sounds like a good plan to me.
> >
> > #4 is the trickiest, and I think it’d be good to give users a bit of
> > time so they can start adjusting before deprecation is in effect.
>
> #4 is trickiest for another reason: there is no future-proof use of
> "guix environment" that works right now and will continue to work. Nor
> is there any way to see, when looking at a command line, whether it's
> old-style or new-style, if neither --ad-hoc nor --inputs-of are present.
> This means that all existing documentation (tutorials etc.) will become
> misleading in the future. Worse, even documentation written today, in
> full awareness of a coming change, can't do better than saying "watch
> out, this will do something else in the future".

I do not understand what is the issue for the time-traveling if it is
documented.
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>".

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.


> The first rule of backwards-compatibility is: never change the meaning
> of an existing valid command/API. Add new valid syntax, deprecate old
> valid syntax, but don't change the meaning of something that was and
> will be valid.

I agree on the rule.
But it is mitigated but the number of users and the popularity of the tool. ;-)


> How about a more drastic measure: deprecate "guix environment" and
> introduce a new subcommand with the desired new behaviour?

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.
;-)

What about "guix shell"?


All the best,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.