From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Tue, 17 Dec 2019 14:30:48 -0800 Message-ID: <20191217223048.GA3741@PhantoNv4ArchGx.localdomain> References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> Reply-To: Bengt Richter 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]:39178) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihLMz-0006wx-Km for guix-devel@gnu.org; Tue, 17 Dec 2019 17:31:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihLMx-00012V-QV for guix-devel@gnu.org; Tue, 17 Dec 2019 17:31:09 -0500 Received: from imta-37.everyone.net ([216.200.145.37]:50494 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ihLMx-0000t1-Ht for guix-devel@gnu.org; Tue, 17 Dec 2019 17:31:07 -0500 Content-Disposition: inline In-Reply-To: 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: =?utf-8?B?R8OhYm9y?= Boskovits Cc: Guix-devel , 38529@debbugs.gnu.org Hi G=C3=A1bor, Konrad, et al On +2019-12-17 10:14:12 +0100, G=C3=A1bor Boskovits wrote: > Hello Konrad, >=20 > Konrad Hinsen ezt =C3=ADrta (id=C5=91pont:= 2019. dec. > 17., Ke 7:52): >=20 > > 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 > > >> a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviou= r, > > >> 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. No= r > > 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 prese= nt. > > This means that all existing documentation (tutorials etc.) will beco= me > > 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 meanin= g > > 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 think it is important to consider context when talking about meaning. 1. the level and the interpreter of the command: The first level is usually the shell (typicallly bash) from logind, but there is systemd and/or shepherd before that, and there is bootloa= der and UEFI and before that also accepting and/or passing commands throug= h to the kernel via the kernel command line (cf. cat /proc/cmdline ). The general pattern I mostly see for a given interpreter is =20 verb -adverb* (-adjective-for: object-name)* sub-command? implicit-or-= object-for-verb* Consider whether your new name reinforces a good convention or forks i= t. Consider whether proposed usage translates easily to a natural languag= e explanation. Does guix have a cli design best practices doc, BTW? =20 right now we are talking about the use case where verb=3Dguix and subcommand=3Denvironment 2. project community conventions Specialized areas often have their own jargon and abbreviated refrence= s so an unfortunate choice of name can cause distracting disambiguation = searches. Before settling on a new name xxx, even for a sub-command, I would say at= least first do the following at the command line: which xxx xxx --version xxx --help info xxx man xxx apropos xxx =20 #check for same prefix, case-insensitively, # e.g. env might be tempting, as seen in this thread :) --8<---------------cut here---------------start------------->8--- echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -in= ame "env*" 2>/dev/null);done --8<---------------cut here---------------end--------------->8--- # -name "*xxx*" may also be a good idea, but the prefix is most import= ant # env* produces /usr/bin/env /usr/bin/envsubst guix search xxx guix package -A xxx wikipedia search on xxx, e.g. lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.ph= p?search=3Dxxx |less You get the idea, I'm sure ;-) =20 > > How about a more drastic measure: deprecate "guix environment" and > > introduce a new subcommand with the desired new behaviour? > > SGTM, with some caveats Good, since calling different things by the same name is always going to = be problematic. Iffy, since calling the same thing by different names may reduce future n= aming options, and may muddy the peer-name namespace, so maybe consider using sub-com= mands or -adverb. > That is also the other option I was thinking about. Do you have any goo= d > 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. > Me neither :) > > > > Cheers, > > > > Konrad. > > > Best regard, > g_bor >=20 HTH in some way :) --=20 Regards, Bengt Richter