[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#38529: Make --ad-hoc the default for guix environment proposed d

From: Konrad Hinsen
Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Date: Tue, 17 Dec 2019 07:49:21 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1

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
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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]