From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Tue, 17 Dec 2019 10:14:12 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002673950599e2c132" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42744) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ih8wZ-0006z0-HR for bug-guix@gnu.org; Tue, 17 Dec 2019 04:15:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ih8wY-0007iy-9J for bug-guix@gnu.org; Tue, 17 Dec 2019 04:15:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:34730) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ih8wY-0007is-6A for bug-guix@gnu.org; Tue, 17 Dec 2019 04:15:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ih8wY-0000Z3-1E for bug-guix@gnu.org; Tue, 17 Dec 2019 04:15:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Konrad Hinsen Cc: Guix-devel , 38529@debbugs.gnu.org --0000000000002673950599e2c132 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Konrad, Konrad Hinsen ezt =C3=ADrta (id=C5=91pont: 201= 9. dec. 17., Ke 7:52): > On 16/12/2019 23:09, Ludovic Court=C3=A8s 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=E2=80=99d be good to give users a b= it 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? > That is also the other option I was thinking about. Do you have any good idea in mind as how to call it? Of course the classic guix environment2 comes to my mind, but it does not look very appealing to me. > > > Cheers, > > Konrad. > Best regard, g_bor > > > > --0000000000002673950599e2c132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> ezt =C3=ADrta (id= =C5=91pont: 2019. dec. 17., Ke 7:52):
On 16/12/2019 23:09, Ludovic Court=C3=A8s 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 (ye= s,
>> 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
>>=C2=A0 =C2=A0 a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the curren= t behaviour,
>>=C2=A0 =C2=A0 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=E2=80=99d 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 <= br> 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 "wa= tch
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" an= d
introduce a new subcommand with the desired new behaviour?
=
That is also the other option I was thinking = about. Do you have any good idea in mind as how to call it? Of course the c= lassic guix environment2 comes to my mind, but it does not look very appeal= ing to me.


Cheers,

=C2=A0=C2=A0 Konrad.
Best reg= ard,
g_bor



--0000000000002673950599e2c132--