From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: 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__42442.8127518453$1576621945$gmane$org@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: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39600) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihLNr-0007H5-VM for bug-guix@gnu.org; Tue, 17 Dec 2019 17:32:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihLNq-00028K-IF for bug-guix@gnu.org; Tue, 17 Dec 2019 17:32:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:36514) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihLNq-00027O-Cx for bug-guix@gnu.org; Tue, 17 Dec 2019 17:32:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ihLNq-00063U-7v for bug-guix@gnu.org; Tue, 17 Dec 2019 17:32:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline 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: =?UTF-8?Q?G=C3=A1bor?= Boskovits Cc: Guix-devel , 38529@debbugs.gnu.org Hi Gábor, Konrad, et al On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote: > Hello Konrad, > > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): > > > 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. > > 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 bootloader and UEFI and before that also accepting and/or passing commands through to the kernel via the kernel command line (cf. cat /proc/cmdline ). The general pattern I mostly see for a given interpreter is verb -adverb* (-adjective-for: object-name)* sub-command? implicit-or-object-for-verb* Consider whether your new name reinforces a good convention or forks it. Consider whether proposed usage translates easily to a natural language explanation. Does guix have a cli design best practices doc, BTW? right now we are talking about the use case where verb=guix and subcommand=environment 2. project community conventions Specialized areas often have their own jargon and abbreviated refrences 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 #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 -iname "env*" 2>/dev/null);done --8<---------------cut here---------------end--------------->8--- # -name "*xxx*" may also be a good idea, but the prefix is most important # 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.php?search=xxx |less You get the idea, I'm sure ;-) > > 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 naming options, and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb. > 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. > Me neither :) > > > > Cheers, > > > > Konrad. > > > Best regard, > g_bor > HTH in some way :) -- Regards, Bengt Richter