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: Fri, 13 Dec 2019 17:27:52 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: 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: zimoun Cc: Guix-devel , 38529@debbugs.gnu.org List-Id: guix-devel.gnu.org Hello, Let me try again :) zimoun ezt =C3=ADrta (id=C5=91pont: 2019. dec. 1= 3., P, 13:02): > > Hi G=C3=A1bor, > > > On Thu, 12 Dec 2019 at 21:54, G=C3=A1bor Boskovits = wrote: > > > zimoun ezt =C3=ADrta (id=C5=91pont: 2019. de= c. 12., Cs=C3=BC 17:47): > > >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > >> with a different effect? Or why do we want to conserve this option > >> name? > >> It appears to me simpler to give another name, for example > >> "--inputs-of". And it is more meaningful. > > > > Sorry for the confusion. Ad-hoc should be retained with the same effect= , so that we do not break existing scripts. > > Renamin the option would be ok. It even makes sense to me. > > What I propose is: > > - keep the option "--ad-hoc" with the current behavior; so same effect > - add a new option "--inputs-of" with the new behavior; name more meani= ngful > - and two env variables; to not break existing scripts > > > >> First, when "--ad-hoc" is used then it reports a warning: deprecated > >> option and falls in the current behavior. > >> When "--inputs-of" is used then it falls in the new behavior. > >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > > > That could be done. The problem is caused by uses of guix environment t= hat does not use any of these options. Those mean different things after th= e change. > > The transition to such use-case was described below with the > introduction of 2 env variables. :-) > > > >> # Alice > >> $ guix environment foo --ad-hoc bar > >> Warning: deprecated... explanations... > >> instead use: > >> guix environment bar --inputs-of foo > >> > >> # Bob > >> $ guix environment bar --inputs-of foo > >> > >> > >> Second, the previous "guix environment foo" (dependencies of foo) is > >> inconsistent with the new "guix environment bar" (only the package > >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > >> variable to distinguish both, as you said. > > > > Ok. > > It is the easy part. ;-) > > > Now the hard part: avoid to break existing scripts. > > >> # Alice > >> $ guix environment foo > >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=3D1 > >> turn off the warning: GUIX_ENVIRONMENT_NOWARNING=3D1 > >> > >> And Alice has now a new shell with the package foo. If she wants the > >> dependencies, she has two options: > >> > >> $ GUIX_ENVIRONMENT=3D1 guix environment foo > >> or > >> $ guix environment --inputs-of foo > >> > >> > >> # Bob > >> $ guix environment bar > >> Warning: previous behavior requires GUIX_ENVIRONMENT > >> > >> And if Bob is annoyed by the warnings each time, he globally turns off > >> with the variable GUIX_ENVIRONMENT_NOWARNING=3D1. > >> > >> > >> Couple of months later -- after the period adoption -- we remove the > >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > >> still keeping the warning with the "--ad-hoc" option. And then, after > >> we can remove the "--ad-hoc" option if required. > > > > We could recommend simply to use something like: > > GUIX_ENVIRONMENT_DEPRECATED=3D0 guix environment ... > > Instead in existing scripts that are fixed to use the new syntax. This = indeed looks like a better solution, and it is less of a maintenance burden= . Good idea. > > My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only > be used by the scripts that call "guix environment pkg" without the > options "--ad-hoc" or "--inputs-of". And I think that it represents > really few scripts in real life. :-) > > > > Summarizing: > > Introduce the environment variable. > > For fixed scripts recommend unsetting the environment variable. > > I am not to get your plan. :-) > > > Cheers, > simon 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. This would minimze friction, as there will be a few scripts falling under 4= . This would also allow mirgating such scripts one by one. be defining GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using GUIX_ENVIRONMENT_DEPRECATED=3D0 guix environment ... in scripts that are fixed to use the new syntax. What do you think? Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21