bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38529: Make --ad-hoc the default for guix environment proposed depre


From: zimoun
Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Date: Fri, 13 Dec 2019 13:02:27 +0100

Hi Gábor,


On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits <address@hidden> wrote:

> zimoun <address@hidden> ezt írta (időpont: 2019. dec. 12., Csü 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 meaningful
  - 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 that 
> does not use any of these options. Those mean different things after the 
> 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=1
>>                turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1
>>
>> And Alice has now a new shell with the package foo. If she wants the
>> dependencies, she has two options:
>>
>> $ GUIX_ENVIRONMENT=1 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=1.
>>
>>
>> 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=0 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]