From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Deprecating =?utf-8?Q?=E2=80=98guix_environment=E2=80=99=3F?= Date: Thu, 19 Dec 2019 17:31:24 +0100 Message-ID: <87k16snuoz.fsf_-_@gnu.org> References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44247) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihyhz-0005tF-Vo for guix-devel@gnu.org; Thu, 19 Dec 2019 11:31:29 -0500 In-Reply-To: (Konrad Hinsen's message of "Tue, 17 Dec 2019 07:49:21 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Konrad Hinsen Cc: guix-devel@gnu.org, 38529@debbugs.gnu.org Hi Konrad, Konrad Hinsen skribis: > 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 bi= t 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. Yeah. Clearly there=E2=80=99s a tension between that and keeping Guix open to cha= nges. > How about a more drastic measure: deprecate "guix environment" and > introduce a new subcommand with the desired new behaviour? That has the advantage of avoiding the problem you mention altogether while also allowing for further changes. The hard question then becomes: what do we call it? I vote against abbreviations. :-) Also, what other goals would we set for that command? How would we frame it in the set of commands? Thanks, Ludo=E2=80=99.