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

Previous Next

Package: guix;

Reported by: Pierre Neidhardt <mail <at> ambrevar.xyz>

Date: Sun, 8 Dec 2019 15:43:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
To: guix-devel <at> gnu.org, 38529 <at> debbugs.gnu.org
Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Date: Tue, 17 Dec 2019 07:49:21 +0100
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".

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.

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


Cheers,

  Konrad.






This bug report was last modified 2 years and 358 days ago.

Previous Next


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