Make --pure the default for `guix environment'?

OpenSubmitted by Pierre Neidhardt.
Details
20 participants
  • Arne Babenhauserheide
  • Bengt Richter
  • Gábor Boskovits
  • Brett Gilio
  • Christopher Lemmer Webber
  • Danny Milosavljevic
  • Thompson, David
  • EuAndreh
  • Jesse Gibbons
  • Konrad Hinsen
  • Kyle Meyer
  • Leo Famulari
  • Ludovic Courtès
  • Pierre Neidhardt
  • Maxim Cournoyer
  • raingloom
  • Ricardo Wurmus
  • Taylan Kammer
  • Andy Wingo
  • zimoun
Owner
unassigned
Severity
normal
P
P
Pierre Neidhardt wrote on 8 Dec 2019 16:42
(address . bug-guix@gnu.org)
87eexeu8mo.fsf@ambrevar.xyz
--pure seems to be the more sensible behaviour. "Impure" environmentscan have unexpected behaviours, so it makes sense to only allow themwhen the user explicitly asks for it.
-- Pierre Neidhardthttps://ambrevar.xyz/
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl3tGc8ACgkQm9z0l6S7zH/MHQgApSwFQkblgyaCyxB1Sg11edxeCLCPTDaJClGB9KCfvxpQUXTniTxvwPD/5y/P12V+MinvUKRm3zHucKkurbfikL9GkTw1A589fvrAqiRbM86aoImkumttJp5u6DQIkRY6WMlB+yGx3T/reFe/Be3G4fNnXCe6POPap98jWQY2vJPOPNsMPtXliS5aiOzOHxCbElpIIUejyl0vbQkzrNXqn5Y95yn2Ymy1FahTjHwmscziYRZsnY2Km+W4Ew15gj7wzBPmCq1QeJ9jsoFynOV7pXZnOdA9RBOSZu0kGvXFZkVXdTtrqv8/Lg31mS9FNKno/LsaFqqm4jOBm96Ze3OhIw===MXkn-----END PGP SIGNATURE-----
Z
Z
zimoun wrote on 8 Dec 2019 22:03
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 38529@debbugs.gnu.org)
CAJ3okZ3WnG87m=jQw08M9ER+=9FS0NVx=uALHK_-4LuD50KhvA@mail.gmail.com
Hi Pierre,
I agree.
And also change the default which populates by the dependencies. Something like:
guix environment foo --inputs-of bar
should spawn an environment containing foo and the dependencies bar.Well, keeping the --ad-hoc option for compatibility.

What do you think?
All the best,simon
L
L
Leo Famulari wrote on 8 Dec 2019 23:43
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 38529@debbugs.gnu.org)
20191208224304.GA4213@jasmine.lan
On Sun, Dec 08, 2019 at 04:42:07PM +0100, Pierre Neidhardt wrote:
Toggle quote (4 lines)> --pure seems to be the more sensible behaviour. "Impure" environments> can have unexpected behaviours, so it makes sense to only allow them> when the user explicitly asks for it.
I don't have an opinion about this in general except that I think that--ad-hoc should continue to work the way it does now, without --purebeing implied.
M
M
Maxim Cournoyer wrote on 9 Dec 2019 06:23
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)(address . 38529@debbugs.gnu.org)
87tv6aoyx0.fsf@gmail.com
Hi Pierre,
Pierre Neidhardt <mail@ambrevar.xyz> writes:
Toggle quote (4 lines)> --pure seems to be the more sensible behaviour. "Impure" environments> can have unexpected behaviours, so it makes sense to only allow them> when the user explicitly asks for it.
Unfortunately Guix packages often don't work well with --pure. Be itmagit that depends on git, or Emacs that depend or coreutils, etc.,there are many things that are expected to be propagated and aren'texplicitly, by omission or sometimes for closure's size sake (when thefeature is optional). We could argue that is a good reason for theproposed change :-).
I think environments are great mostly for hacking and trying stuffquickly, where the guarantees of Guix do not matter as much as forprofiles (and if they did, you'd be better with guix environment--container anyway).
So, I guess that makes me more on the side of "let's no change thedefaults for now".
Maxim
J
J
Jesse Gibbons wrote on 9 Dec 2019 18:37
e56ae49d56e50c40a8e1d279e7d0b2b14761935b.camel@gmail.com
On Sun, 2019-12-08 at 16:42 +0100, Pierre Neidhardt wrote:
Toggle quote (4 lines)> --pure seems to be the more sensible behaviour. "Impure" environments> can have unexpected behaviours, so it makes sense to only allow them> when the user explicitly asks for it.>
--pure environments sometimes miss important environment variables. Tryrunning any app that depends on X and doesn't fallback to a console mode ina pure environment.for example, "guix environment --pure --ad-hoc pavucontrol -- pavucontrol"gives me an error: No protocol specifiedUnable to init server: Could not connect: Connectionrefused


Similarly, "guix environment --pure --ad-hoc gnubik -- gnubik" gives me anerror:No protocol specified
(gnubik:29707): Gtk-WARNING **: 10:03:28.753: cannot open display: :1




"guix environment --pure --ad-hoc gedit -- gedit":No protocol specifiedUnable to init server: Could not connect: Connection refused
(org.gnome.gedit:31542): Gtk-WARNING **: 10:08:07.401: cannot open display::1


Making --pure the default for "guix environment" would make things morecomplicated for users wanting to temporarily run GUI apps unless we fix thisissue first. I furthermore suspect some tests fail because of this issue.
T
T
Thompson, David wrote on 9 Dec 2019 19:46
(name . zimoun)(address . zimon.toutoune@gmail.com)
CAJ=RwfabiMuyx_JXP+KU76kCCRAX0zofN14YJ5wEi-YMwNW_YQ@mail.gmail.com
Hi,
I have long thought that --ad-hoc should be implied, as that is themode I use 99% of the time, but I disagree that --pure should be thedefault. Most of the time I (and I suspect most other users) just wantto temporarily augment the current environment with a package or twoand I think that shouldn't require any special flags (neither --ad-hocnor --pure). The current default behavior of making an environmentfrom package dependencies is because that's how nix-shell worked (orat least how I thought it worked) and 'guix environment' was createdas a clone of that tool.
- Dave
B
B
Brett Gilio wrote on 9 Dec 2019 21:17
(name . Thompson, David)(address . dthompson2@worcester.edu)
87blshuucr.fsf@posteo.net
"Thompson, David" <dthompson2@worcester.edu> writes:
Toggle quote (14 lines)> Hi,>> I have long thought that --ad-hoc should be implied, as that is the> mode I use 99% of the time, but I disagree that --pure should be the> default. Most of the time I (and I suspect most other users) just want> to temporarily augment the current environment with a package or two> and I think that shouldn't require any special flags (neither --ad-hoc> nor --pure). The current default behavior of making an environment> from package dependencies is because that's how nix-shell worked (or> at least how I thought it worked) and 'guix environment' was created> as a clone of that tool.>> - Dave
I was waiting for somebody to say this. But, I am 100% in agreement withDave as far as the behavior of --pure. I really would like to see eithernothing change, or we make --ad-hoc the implied default.
My reasoning confers with Dave's logic.
-- Brett M. Giliohttps://git.sr.ht/~brettgilio/
L
L
Ludovic Courtès wrote on 10 Dec 2019 18:16
(name . Thompson, David)(address . dthompson2@worcester.edu)
87o8wgksnp.fsf@gnu.org
Hello!
"Thompson, David" <dthompson2@worcester.edu> skribis:
Toggle quote (4 lines)> I have long thought that --ad-hoc should be implied, as that is the> mode I use 99% of the time, but I disagree that --pure should be the> default.
I very much agree with that. I don’t think ‘--pure’ should be thedefault, because there are valid use cases for that.
As for ‘--ad-hoc’: making it the default is technically easy. Thedifficulty is to come up with a nice transition/deprecation mechanism sothat we don’t break everyone’s script overnight.
Ideas on how to achieve it are welcome!
Thanks,Ludo’.
G
G
Gábor Boskovits wrote on 12 Dec 2019 12:23
Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . Guix-devel)(address . guix-devel@gnu.org)(address . 38529@debbugs.gnu.org)
CAE4v=phY+7CTKMf8Y3a9p4okfqtMGOWu9kd2Nu6oCJW8OsK3Lw@mail.gmail.com
Hello guix,
Based on discussion on IRC the following plan for deprecation might work.Comments are welcome:
1.Make guix environment aware of an environment variable:GUIX_ENVIRONMENT_DEPRECATED_AD_HOCif this is defined, then fall back to the current behaviour.
Motivation: this would enable most script users to bypass the problem,while fixing them, but it makes the users aware that they are using adeprecated feature.At the same time this should come with a news entry, an any otherannouncements should be made that we usually do, so that support don'tget overloaded. Is should also be announced that two releases laterthe code supporting this will be removed, so that we don't have tomaintain it, but allow enough time for adoption.
2. add a flag to guix environment, something like--ignore-deprecated-ad-hoc, that makes guix environment ignore theenvironment variable, and default to the new behaviour.
Motivation: so that scripts can be fixed individually by modifying theguix environment call to the new version, and adding the flag, so thatit does not cause a problem in the trasitional period while theenvironment variable is defined.
3. on the specified release remove the environment variable supportcode, and make the flag a noop, and also deprecated.
4. later if needed after an adoption period we can remove the flag.

Best regards,g_bor-- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Z
Z
zimoun wrote on 12 Dec 2019 17:47
(name . Gábor Boskovits)(address . boskovits@gmail.com)
CAJ3okZ3+-yAfRpYDHz-jYONguOPWjff0iWZ_7NPEz6x5mbOO1w@mail.gmail.com
Hi Gábor,
Thank you for summarizing the discussion on IRC that I missed.
Maybe I miss a point. Is the aim to conserve the "--ad-hoc" optionwith a different effect? Or why do we want to conserve this optionname?It appears to me simpler to give another name, for example"--inputs-of". And it is more meaningful.

To be concrete, the different cases; (-) means current behavior and(+) the new one:
1.- guix environment foo+ guix environment --inputs-of foo
2.- guix environment --ad-hoc bar+ guix environment bar

First, when "--ad-hoc" is used then it reports a warning: deprecatedoption 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".

In other words, with the same future guix version,
# 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) isinconsistent with the new "guix environment bar" (only the packagebar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATEDvariable to distinguish both, as you said.
# 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 thedependencies, she has two options:
$ GUIX_ENVIRONMENT=1 guix environment fooor$ 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 offwith the variable GUIX_ENVIRONMENT_NOWARNING=1.

Couple of months later -- after the period adoption -- we remove thevariables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED;still keeping the warning with the "--ad-hoc" option. And then, afterwe can remove the "--ad-hoc" option if required.

Maybe a miss a point. But the addition of the flag appears"--too-long-to-type" to me ugly.

What do you think?
All the best,simon
Z
Z
zimoun wrote on 12 Dec 2019 20:33
Re: bug#38529: Make --pure the default for `guix environment'?
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
CAJ3okZ0Xi1vi13pogXs=6O-yw3VQwJfLCo2hsxVNEcgbCmctnQ@mail.gmail.com
Hi,
On Mon, 9 Dec 2019 at 18:38, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
Toggle quote (6 lines)> for example, "guix environment --pure --ad-hoc pavucontrol -- pavucontrol"> gives me an error:> No protocol specified> Unable to init server: Could not connect: Connection> refused
I do not experiment this error.

Toggle quote (6 lines)> Similarly, "guix environment --pure --ad-hoc gnubik -- gnubik" gives me an> error:> No protocol specified>> (gnubik:29707): Gtk-WARNING **: 10:03:28.753: cannot open display: :1
I do not experiment this error.

Toggle quote (7 lines)> "guix environment --pure --ad-hoc gedit -- gedit":> No protocol specified> Unable to init server: Could not connect: Connection refused>> (org.gnome.gedit:31542): Gtk-WARNING **: 10:08:07.401: cannot open display:> :1
Instead I experiment this warning:
(org.gnome.gedit:19087): dconf-WARNING **: 20:31:27.734: failed tocommit changes to dconf: Failed to execute child process ?dbus-launch?(No such file or directory)


All the best,simon
G
G
Gábor Boskovits wrote on 12 Dec 2019 21:54
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . zimoun)(address . zimon.toutoune@gmail.com)
CAE4v=piMnBhHWpbB60qMRnnDNwqkuddfNv7cEihr9+5-52k2OA@mail.gmail.com
Hello,
zimoun <zimon.toutoune@gmail.com> ezt írta (időpont: 2019. dec. 12., Csü17:47):
Toggle quote (10 lines)> Hi Gábor,>> Thank you for summarizing the discussion on IRC that I missed.>> 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, sothat we do not break existing scripts.Renamin the option would be ok. It even makes sense to me.
Toggle quote (19 lines)>>> To be concrete, the different cases; (-) means current behavior and> (+) the new one:>> 1.> - guix environment foo> + guix environment --inputs-of foo>> 2.> - guix environment --ad-hoc bar> + guix environment bar>>> 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 thatdoes not use any of these options. Those mean different things after thechange.
Toggle quote (19 lines)>>> In other words, with the same future guix version,>> # 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.
Toggle quote (31 lines)>> # 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.>>> Maybe a miss a point. But the addition of the flag appears> "--too-long-to-type" to me ugly.>
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. Thisindeed looks like a better solution, and it is less of a maintenanceburden. Good idea.
Toggle quote (8 lines)>>> What do you think?>> All the best,> simon>
Summarizing:Introduce the environment variable.For fixed scripts recommend unsetting the environment variable.
That looks like a better plan. Thanks for your insights.
Best regards,g_bor
Toggle quote (1 lines)>
Attachment: file
Z
Z
zimoun wrote on 13 Dec 2019 13:02
(name . Gábor Boskovits)(address . boskovits@gmail.com)
CAJ3okZ3gJDdDKWERLANp+7ueSirEZ7hH=YKa3nhCAzCzAz1TGg@mail.gmail.com
Hi Gábor,

On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits <boskovits@gmail.com> wrote:
Toggle quote (11 lines)> zimoun <zimon.toutoune@gmail.com> 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

Toggle quote (7 lines)>> 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 theintroduction of 2 env variables. :-)

Toggle quote (17 lines)>> # 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.
Toggle quote (31 lines)>> # 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 onlybe used by the scripts that call "guix environment pkg" without theoptions "--ad-hoc" or "--inputs-of". And I think that it representsreally few scripts in real life. :-)

Toggle quote (4 lines)> Summarizing:> Introduce the environment variable.> For fixed scripts recommend unsetting the environment variable.
I am not to get your plan. :-)

Cheers,simon
G
G
Gábor Boskovits wrote on 13 Dec 2019 17:27
(name . zimoun)(address . zimon.toutoune@gmail.com)
CAE4v=pgevGwP6+jSY-+0DPdtvK60sEvd-uibqhRawuo6N1pL-Q@mail.gmail.com
Hello,
Let me try again :)
zimoun <zimon.toutoune@gmail.com> ezt írta (időpont: 2019. dec. 13., P, 13:02):
Toggle quote (104 lines)>> Hi Gábor,>>> On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits <boskovits@gmail.com> wrote:>> > zimoun <zimon.toutoune@gmail.com> 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
So in a more algorithmic manner:1. if ad-hoc and inputs-of is present at the same invocation: failhard. (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 youdescribed)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 thenew 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 definingGUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and usingGUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that arefixed to use the new syntax.

What do you think?
Best regards,g_bor-- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Z
Z
zimoun wrote on 13 Dec 2019 17:32
(name . Gábor Boskovits)(address . boskovits@gmail.com)
CAJ3okZ1L_nmhdOwsxFmmTA3v9GiB=6NU2jSZFF7AgY-fctHtsA@mail.gmail.com
Hi Gábor,
Sorry to be slow. :-)
On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits <boskovits@gmail.com> wrote:

Toggle quote (21 lines)> 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=0 guix environment ... in scripts that are> fixed to use the new syntax.>>> What do you think?
I am perfectly aligned! :-)It is exactly what I have tried to describe.Sorry again for being slow.
Thank you.Do you plan to implement it? Do I give a try?

All the best,simon
G
G
Gábor Boskovits wrote on 13 Dec 2019 17:41
(name . zimoun)(address . zimon.toutoune@gmail.com)
CAE4v=pj_+UpJrbM77upTfRsxvmVHyCBXRi-2_bZB5fbHz6cgNQ@mail.gmail.com
Hello Zimoun,
zimoun <zimon.toutoune@gmail.com> ezt írta (időpont: 2019. dec. 13., P, 17:32):
Toggle quote (5 lines)>> Hi Gábor,>> Sorry to be slow. :-)
I probably just did not express myself clearly enough.
Toggle quote (27 lines)>> On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits <boskovits@gmail.com> 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.> >> > 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=0 guix environment ... in scripts that are> > fixed to use the new syntax.> >> >> > What do you think?>> I am perfectly aligned! :-)
Great!
Toggle quote (3 lines)> It is exactly what I have tried to describe.> Sorry again for being slow.
I am sorry for the confusion, my communication tends to slugghish, anI am also a bit bound todo some hand-waving :) I hope to improve on that
Toggle quote (4 lines)>> Thank you.> Do you plan to implement it? Do I give a try?
I would like to hear something from Ludo, as he was also a participantof the IRC discussion.
After that I would not mind if you gave it a try, if you would like.Otherwise I will implement it.
Toggle quote (6 lines)>>> All the best,> simon

Best regards,g_bor-- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
L
L
Ludovic Courtès wrote on 16 Dec 2019 23:09
(name . Gábor Boskovits)(address . boskovits@gmail.com)
87k16vdise.fsf@gnu.org
Hello,
Gábor Boskovits <boskovits@gmail.com> skribis:
Toggle quote (12 lines)> 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 oftime so they can start adjusting before deprecation is in effect.
Namely, we could start by introducing ‘--inputs-of’ and emitting awarning in case #4 to suggest the use of ‘--inputs-of’. Apart from thewarning, case #4 would still behave the same as now.
Three (?) months later, we implement what you describe above. Hopefullyby that time many people got used to ‘--inputs-of’.
Thoughts?
Ludo’.
K
K
Konrad Hinsen wrote on 17 Dec 2019 07:49
e992ac46-37b9-ba12-83cc-6694427acd31@fastmail.net
On 16/12/2019 23:09, Ludovic Courtès wrote:
Toggle quote (16 lines)> 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.
How about a more drastic measure: deprecate "guix environment" and introduce a new subcommand with the desired new behaviour?

Cheers,
  Konrad.
G
G
Gábor Boskovits wrote on 17 Dec 2019 10:14
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAE4v=pjc5pWiaaB17tJnpO=O0=M5xrEWhyvWMLRaiLy5V19Y5Q@mail.gmail.com
Hello Konrad,
Konrad Hinsen <konrad.hinsen@fastmail.net> ezt írta (időpont: 2019. dec.17., Ke 7:52):
Toggle quote (34 lines)> 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.>> How about a more drastic measure: deprecate "guix environment" and> introduce a new subcommand with the desired new behaviour?>
That is also the other option I was thinking about. Do you have any goodidea in mind as how to call it? Of course the classic guix environment2comes to my mind, but it does not look very appealing to me.
Toggle quote (6 lines)>>> Cheers,>> Konrad.>
Best regard,g_bor
Toggle quote (4 lines)>>>>
Attachment: file
K
K
Kyle Meyer wrote on 17 Dec 2019 14:33
87pngncc0n.fsf@kyleam.com
Gábor Boskovits <boskovits@gmail.com> writes:
Toggle quote (2 lines)> Konrad Hinsen <konrad.hinsen@fastmail.net> ezt írta (időpont: 2019. dec.> 17., Ke 7:52):
[...]
Toggle quote (7 lines)>> How about a more drastic measure: deprecate "guix environment" and>> introduce a new subcommand with the desired new behaviour?>>> 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.
Perhaps "guix env"?
B
B
Brett Gilio wrote on 17 Dec 2019 15:22
(name . Kyle Meyer)(address . kyle@kyleam.com)
4ee893ad-b489-4e98-b716-e418cd3b8049@localhost
Dec 17, 2019 7:34:17 AM Kyle Meyer :
Toggle quote (21 lines)> G�bor Boskovits writes:>>> > Konrad Hinsen ezt �rta (id?pont: 2019. dec.> > 17., Ke 7:52):> >> [...]>> >> > > How about a more drastic measure: deprecate "guix environment" and> > > introduce a new subcommand with the desired new behaviour?> > >> > >> > 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.> >>> Perhaps "guix env"?>
+1 for guix env
Z
Z
zimoun wrote on 17 Dec 2019 18:07
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAJ3okZ0Fw=02cDwdn5GuiDCyUNOUY=YaGyrFyHE5qWsOQTLASQ@mail.gmail.com
Hi Konrad,
On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Toggle quote (27 lines)>> 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".
I do not understand what is the issue for the time-traveling if it isdocumented.Maybe I miss a point. It is not: "watch out, this will do somethingelse in the future" but "watch out, this was doing something else inthe past and the change happened the <date> in <commit>".
First, I am not convinced that there is not so much scripts that willbe broken. And second, I am not convinced neither that these veryscripts need time-traveling.

Toggle quote (5 lines)> 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 agree on the rule.But it is mitigated but the number of users and the popularity of the tool. ;-)

Toggle quote (3 lines)> How about a more drastic measure: deprecate "guix environment" and> introduce a new subcommand with the desired new behaviour?
Yes, it is probably the most adequate to do. But it is sad to loosethe good name "guix environment"... and we know that naming is hard.;-)
What about "guix shell"?

All the best,simon
B
B
Bengt Richter wrote on 17 Dec 2019 23:30
(name . Gábor Boskovits)(address . boskovits@gmail.com)
20191217223048.GA3741@PhantoNv4ArchGx.localdomain
Hi Gábor, Konrad, et al
On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote:
Toggle quote (37 lines)> Hello Konrad,> > Konrad Hinsen <konrad.hinsen@fastmail.net> 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 leastfirst 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 :)
Toggle snippet (2 lines) echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done
# -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 ;-)
Toggle quote (3 lines)> > 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.
Toggle quote (5 lines)> 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 :)
Toggle quote (9 lines)> >> > Cheers,> >> > Konrad.> >> Best regard,> g_bor>
HTH in some way :)
-- Regards,Bengt Richter
B
B
Bengt Richter wrote on 18 Dec 2019 00:21
(name . Gábor Boskovits)(address . boskovits@gmail.com)
20191217232118.GA14151@PhantoNv4ArchGx.localdomain
Forgot to add:┌──────────────────────────────────────────────────────────────────────────┐│ guile -c '(use-modules (ice-9 session))(apropos "env") │├──────────────────────────────────────────────────────────────────────────┤│ (guile): getenv #<procedure getenv (_)> ││ (guile): environ #<procedure environ (#:optional _)> ││ (guile): setenv #<procedure setenv (name value)> ││ (guile): interaction-environment #<procedure interaction-environment ()> ││ (guile): putenv #<procedure putenv (_)> ││ (guile): unsetenv #<procedure unsetenv (name)> │└──────────────────────────────────────────────────────────────────────────┘
BTW, it would be really handy to be able to type guile -apropos rest of line as regexfor the effect of ,a rest of line as regexin the guile repl-- Regards,Bengt Richter
K
K
Konrad Hinsen wrote on 18 Dec 2019 10:43
(name . zimoun)(address . zimon.toutoune@gmail.com)
m1pngmrmst.fsf@khs-macbook.home
Hi Simon,
Toggle quote (4 lines)> Maybe I miss a point. It is not: "watch out, this will do something> else in the future" but "watch out, this was doing something else in> the past and the change happened the <date> in <commit>".
Concrete example: I am writing a tutorial about using Guix forreproducible research. It shows several uses of "guix environment", someof them without '–add-hoc' or '–inputs-of'. I know my examples willcease to work in a few months. What am I supposed to do about this?
Toggle quote (4 lines)> First, I am not convinced that there is not so much scripts that will> be broken. And second, I am not convinced neither that these very> scripts need time-traveling.
Perhaps it's just me, but I use "guix environment" quite a lot inscripts, in order to make them more reproducible. Here's a simpleexample:
#!/usr/bin/env bash guix environment --container --ad-hoc gcc-toolchain <<EOF gcc pi.c -o pi ./pi EOF
Toggle quote (8 lines)>> 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 agree on the rule.> But it is mitigated but the number of users and the popularity of the tool. ;-)
Indeed!
Toggle quote (4 lines)> Yes, it is probably the most adequate to do. But it is sad to loose> the good name "guix environment"... and we know that naming is hard.> ;-)
I definitely agree. As a lesson for the future, maybe we should usenot-so-nice names for new commands during a kind of beta-testing phase.
Cheers, Konrad
Z
Z
zimoun wrote on 18 Dec 2019 14:09
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAJ3okZ3zSS0Rbnu5eLhpYHPvSY1emaj=-estQcjRwiJ3=4RMMA@mail.gmail.com
Hi Konrad,
On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Toggle quote (12 lines)>> Hi Simon,>> > Maybe I miss a point. It is not: "watch out, this will do something> > else in the future" but "watch out, this was doing something else in> > the past and the change happened the <date> in <commit>".>> Concrete example: I am writing a tutorial about using Guix for> reproducible research. It shows several uses of "guix environment", some> of them without '–add-hoc' or '–inputs-of'. I know my examples will> cease to work in a few months. What am I supposed to do about this?
Assuming "guix environment" would stay and following the proposedplan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the topof your script. In this would not be a problem for travelling back intime.

Toggle quote (14 lines)> > First, I am not convinced that there is not so much scripts that will> > be broken. And second, I am not convinced neither that these very> > scripts need time-traveling.>> Perhaps it's just me, but I use "guix environment" quite a lot in> scripts, in order to make them more reproducible. Here's a simple> example:>> #!/usr/bin/env bash> guix environment --container --ad-hoc gcc-toolchain <<EOF> gcc pi.c -o pi> ./pi> EOF
With the proposed plan, this would stay the same. Even, the --ad-hocoption could stay forever for backward compatibility.
The only issue is for example:
#!/usr/bin/env bash guix environment --container gmsh <<EOF mkdir build cd build cmake .. make ./bin/gmsh EOF
And I not convinced that this kind of scripts need to be robust fortime-travelling, I mean it is easy to correct adding the --inputs-ofoption or set the GUIX_ENVIRONMENT_DEPRECATED variable.

Toggle quote (7 lines)> > Yes, it is probably the most adequate to do. But it is sad to loose> > the good name "guix environment"... and we know that naming is hard.> > ;-)>> I definitely agree. As a lesson for the future, maybe we should use> not-so-nice names for new commands during a kind of beta-testing phase.
What do you think about "guix shell" for the new "guix environment" behaviour?
What the others think?New name (easier) vs transitional plan (trickier)?And new names proposal: - guix env - guix shell?

All the best,simon
A
A
Arne Babenhauserheide wrote on 18 Dec 2019 21:55
(address . bug-guix@gnu.org)
87zhfp2w11.fsf@web.de
Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
Toggle quote (11 lines)> Hi Simon,>>> Maybe I miss a point. It is not: "watch out, this will do something>> else in the future" but "watch out, this was doing something else in>> the past and the change happened the <date> in <commit>".>> Concrete example: I am writing a tutorial about using Guix for> reproducible research. It shows several uses of "guix environment", some> of them without '–add-hoc' or '–inputs-of'. I know my examples will> cease to work in a few months. What am I supposed to do about this?
This is the point where we need to ask ourselves:
Should Guix be volatile software? http://stevelosh.com/blog/2012/04/volatile-software/
Also: Software developers should avoid traumatic changes https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
Best wishes,Arne--Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl36klwACgkQE++NRSQDw+un/BAAm1Rm9x6XcSRau9mYwQhxcVFORqZNvPZAUQVixI3vBfoJ7UHig8Abbh26oNdAkCLIUsZ4nQ8p7d9Ev8v17uOyvuw+8j+eiK9BgrmjXpd0f7cjuDuDTIX0QNBEeXmncUDdG3CWnZ5Fa7jcNnGb6ANicnoCIhcTw3eMBCXS/CrqXGw7zIgIpwIUOKnSIpS0RJTnb5rklJE6i5Y1XSAGYeYaMtQZfOnSn23ITgMqd/+ZEM8QojG8j5WKMRchK0VE0p/1l7k0bL6elYcHVAyaCsUWILPJIH+pnYPt4hSQSBbgudZRcvdfVWJ+WXg8fzCKaLKPaA0ZA1W+MLpeLqca4jn1ekpi3OzaDyvwp32FhaxSBbO+DdPuvA103bbZtmMV6PuBz7Pa9NsnRdH41NQlG7oFuo2+L2mEvkxwUYKabt0ge5kap/n7PXsATTewX4I/jk4ugugUJBM5CJ47t1TleTq5UCk/fo76dlLkm0vFgaxWM7bSJKb/t1d1Ds4nn0spHHSo61qMUrynj9LvgEDMHKCWDcDd/irLdwqRe+DpptayH/VH+4j8nwobX01zBExhaU5hEjOhpSD80OE2feq2NQPWtezLjt+7r9veHzM8595iA4PQ7lsxMEWHDmmZtXJyA56Hn7HdW5ClIRaw9yiGHbQ7dDigkZg+lYJQbOh4b6YStiOIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd+pJcAAoJENzPDbMLwQVIJoUD/05tDaFA3KwZaT6Adz1/aQ5/3y9JTM3mOPVlD+ykvqupk4q/1flx96on9QNey5ZTAvF4wpqxhphFLMl5qrkLGBpS7JosVu6eoqdBMy90PnxK1bTlJ6S3jpRjvJ8eHZwc7K8l+JX+xJJ3GFodP8hzlHKApIprazykI3R72unqGhZS=KV24-----END PGP SIGNATURE-----
Z
Z
zimoun wrote on 19 Dec 2019 12:30
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
CAJ3okZ3bHnOzOk2Cdtvh_NZbYGDfA+zzxrAsJk+7=gRYHaL7jw@mail.gmail.com
Hi Arne,
Thank you for the pointers.

On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide <arne_bab@web.de> wrote:
Toggle quote (16 lines)> Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
> >> Maybe I miss a point. It is not: "watch out, this will do something> >> else in the future" but "watch out, this was doing something else in> >> the past and the change happened the <date> in <commit>".> >> > Concrete example: I am writing a tutorial about using Guix for> > reproducible research. It shows several uses of "guix environment", some> > of them without '–add-hoc' or '–inputs-of'. I know my examples will> > cease to work in a few months. What am I supposed to do about this?>> This is the point where we need to ask ourselves:>> Should Guix be volatile software?> http://stevelosh.com/blog/2012/04/volatile-software/
Guix is not a volatile software and will never be. Because it isrooted in time-travelling.The tools "guix pull --commit=", "guix <command> --manifest=", "guixtime-machine" or the "--roll-back" avoid to break what is currentlyworking.Well, the section "The situation" just cannot(*) happen with Guix.That's why Guix is awesome! ;-)
(*) well if one correctly uses Guix which is another story ;-)and it is not perfect yet... see all the discussion about manifest. :-)

Now, let recall the formula (already discussed in this thread :-))
Number of people Time it takes each personusing that part of X to figure out what changedthe program and how to fix it
Hum? I am not convinced that the cost would be high... Because 1. thenumber of people using Guix is not so high (yet!), so 2. I am almostsure we can name the people using "guix environment" in scripts ;-).And 3. the time to figure out what changed is really low -- especiallywith warnings and hints -- and "guix environment foo -- make" wouldreturn an error because of dependencies missing.
Other said, I do not see myself use-cases where the scripts using"guix environment" need to be robust for time-travelling -- the samescript used with current, past and future Guix versions -- because asit was said elsewhere: "environment" can be seen like "temporaryprofile". And temporary means... well temporary. ;-)
Then, the section "The Tradeoff" advices "from newmodule importnew_foo as foo" and IMO it is what the plan proposes with the variableGUIX_ENVIRONMENT_DEPRECATED (tricky point #4).
Last, "volatile" vs "stable" is mitigated by "The future of 'guixenvironment'" [1] which really predates the 1.0. ;-)
[1] https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html

As I said, I am not convinced by the argument: everything would bebroken, too much time to fix the break, etc. and this proposal wouldlead to disaster for the end-user. But it is my opinion based on myrestricted personal experience.

Toggle quote (3 lines)> Also: Software developers should avoid traumatic changes> https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
"Traumatic changes"? Maybe a bit extreme for the change we are talking about...


Well, at the end, what is explicitly your personal opinion? a. Change the behaviour of "guix environment" using the proposed plan?or b. Add a new command? Which one? "guix shell", "guix env" or "guix<you-name-it>"?

All the best,simon
L
L
Ludovic Courtès wrote on 19 Dec 2019 17:31
Deprecating ‘guix environment’?
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
87k16snuoz.fsf_-_@gnu.org
Hi Konrad,
Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
Toggle quote (31 lines)> 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.
Yeah.
Clearly there’s a tension between that and keeping Guix open to changes.
Toggle quote (3 lines)> 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 altogetherwhile also allowing for further changes.
The hard question then becomes: what do we call it? I vote againstabbreviations. :-)
Also, what other goals would we set for that command? How would weframe it in the set of commands?
Thanks,Ludo’.
A
A
Arne Babenhauserheide wrote on 19 Dec 2019 22:39
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . zimoun)(address . zimon.toutoune@gmail.com)
871rt03shq.fsf@web.de
Hi zimoun,
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (9 lines)>> Should Guix be volatile software?>> http://stevelosh.com/blog/2012/04/volatile-software/>> Guix is not a volatile software and will never be. Because it is> rooted in time-travelling.> The tools "guix pull --commit=", "guix <command> --manifest=", "guix> time-machine" or the "--roll-back" avoid to break what is currently> working.
This is taking this a bit too easy. If I can no longer pull, becausethat breaks my Emacs or Gnome, then Guix is broken for me: I can nolonger update my system without first adjusting my config.
Toggle quote (8 lines)> Number of people Time it takes each person> using that part of X to figure out what changed> the program and how to fix it>> Hum? I am not convinced that the cost would be high... Because 1. the> number of people using Guix is not so high (yet!), so 2. I am almost> sure we can name the people using "guix environment" in scripts ;-).
I’m not so sure. Guix is already used in scientific workflows, and thereis existing third-party documentation about using `guix environment`.
And can you name the people using `guix environment` by searchingbackwards in their bash history?
Toggle quote (4 lines)> And 3. the time to figure out what changed is really low -- especially> with warnings and hints -- and "guix environment foo -- make" would> return an error because of dependencies missing.
It took me days to figure out the exact guix environment invocation thatallows me to build the tools for a paper I’m still working on. If thatbreaks, that causes massive anxiety, because I then don’t know whetherI’ll find the time to fix it before I run into deadlines.
Toggle quote (6 lines)> Other said, I do not see myself use-cases where the scripts using> "guix environment" need to be robust for time-travelling -- the same> script used with current, past and future Guix versions -- because as> it was said elsewhere: "environment" can be seen like "temporary> profile". And temporary means... well temporary. ;-)
The same script must always work with future versions. Otherwise thesoftware is volatile.
You don’t need to be able to go back in time, but the path forward mustbe without breakage.
Toggle quote (4 lines)> Then, the section "The Tradeoff" advices "from newmodule import> new_foo as foo" and IMO it is what the plan proposes with the variable> GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).
No, that’s the opposite: from newmodule import new_foo as foo means,that you allow users to define an environment variable called`GUIX_ENVIRONMENT_MODERN`.
Toggle quote (3 lines)> Last, "volatile" vs "stable" is mitigated by "The future of 'guix> environment'" [1] which really predates the 1.0. ;-)
Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,but it wasn’t.
Toggle quote (5 lines)>> Also: Software developers should avoid traumatic changes>> https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html>> "Traumatic changes"? Maybe a bit extreme for the change we are talking about...
I don’t think so. There’s the strong version where it’s obvious: Itleads people to leave a project instantly.
There’s the weaker version which is less obvious: That’s where peoplewho invested efford to follow best practices suddenly find their projectto be written in legacy style, because the best practices changed.
Toggle quote (6 lines)> Well, at the end, what is explicitly your personal opinion?> a. Change the behaviour of "guix environment" using the proposed plan?> or> b. Add a new command? Which one? "guix shell", "guix env" or "guix> <you-name-it>"?
I would opt for b. And then for changing guix to give the most commoncommands when called without argument (as `guix`) — excludingguix environment.
That would not avoid the slow version of traumatic changes, but ifguix environment would keep working and both guix env/guix shell/… andguix environment used the same backend (just with different options),then they would be minimized, because guix environment would not becomea second-class citizen.
Best wishes,Arne--Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl377gMACgkQE++NRSQDw+tujBAAxS1DE0VL+KlggoUcM1PXzAVqmznzZOn3/M24/n2tCWCiK7QfXBOCK3dtQXSYpoozIV2ZHdjc8UpM6Y+xwr+WnJrQsvQAIKOwDT7Dzxa4RHsNV9PmFHOxyJFMas7t4XxYfXJrp48n6baF/xywvrMcWe0L2F8x1e2PF0SXrHKMwb+cg+k0pE0H+02z5n1fd4O6VetyPa3U0XQGcmMqqxDaPY7kfXCA+daqry4/T/F6xli0T9NOBK1C/a4IIQP+YenYlyzKKXTCiZ+0mm6/vx+hGQzvkmGPDYsFsUTvz10dGLEBDoZOTHECcWVNguYEHNDpItMrt/JueN4x7MXwV6eclviaIo8rHMIg1UO4F81KjRwN2Ejr4T46+utX6uvE0k5QPH6Ol01sHDBvfNvC/XztGgN0BJtmsMn5CtbhQx1BWHbNrNVbJIY4Fzev5fBwB7psKG4yDpb58xtgs84PbN5gAK3jW31brOGrTprYpPoQQxxIluXd02vk7j6T/qNroGg3H3W1Q4hHEPCBdtJVAF2lAylCDraPo9eU4j/+odrQDMqB2ISfGbO69xQeLVMvM0UaGVuf4LJfk0rED4eppm9sib0KjgE5Fdy3W9ur/hS94WIBO6XqC6w/35UGWP9wMGDZGWY+donOfO3JZWSmzbjncsUhHJ32bXm6FlN/MWvkM8eIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd++4DAAoJENzPDbMLwQVIPHAD/0ozQwSHXe6qMlZHPs8FDOqXxcX+3onf+Kir9UVQuxUl+jnJTh5FL9vlWvdRb5yk7vKXnY7D2eZ5x68w3Y4sdl9hma+CiFit+M4H5vKQhOGpNTgKHllnVGJ5DFM96V8b4TZR9J3rvr49IjXgbsWP6X+KCE2rULP+YjjzmiCcJIk7=pDkB-----END PGP SIGNATURE-----
Z
Z
zimoun wrote on 19 Dec 2019 23:40
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
CAJ3okZ3gwpjy2cgRj1iOtPX0cTSVBLoxSVaUBxnMEsMCVNUyFg@mail.gmail.com
Hi Arne,
First, have you read the proposal?Or are you (maybe a bit) "overreacting" about the backward compatibility?

On Thu, 19 Dec 2019 at 22:39, Arne Babenhauserheide <arne_bab@web.de> wrote:
Toggle quote (12 lines)> zimoun <zimon.toutoune@gmail.com> writes:
> > Guix is not a volatile software and will never be. Because it is> > rooted in time-travelling.> > The tools "guix pull --commit=", "guix <command> --manifest=", "guix> > time-machine" or the "--roll-back" avoid to break what is currently> > working.>> This is taking this a bit too easy. If I can no longer pull, because> that breaks my Emacs or Gnome, then Guix is broken for me: I can no> longer update my system without first adjusting my config.
So you expect that we would push a patch changing "guix environment"and in the same time break "guix pull, isn't it?Otherwise I do not see your argument.

Toggle quote (7 lines)> > Hum? I am not convinced that the cost would be high... Because 1. the> > number of people using Guix is not so high (yet!), so 2. I am almost> > sure we can name the people using "guix environment" in scripts ;-).>> I’m not so sure. Guix is already used in scientific workflows, and there> is existing third-party documentation about using `guix environment`.
Please point me where.It will save me time instead of reinventing the wheel.

Toggle quote (3 lines)> And can you name the people using `guix environment` by searching> backwards in their bash history?
So what would break?Your workflow: spending 5 minutes to read the warning message and then pressing:C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment <your-complicated-invokation>
(unfair and bitter; sorry!)

Toggle quote (9 lines)> > And 3. the time to figure out what changed is really low -- especially> > with warnings and hints -- and "guix environment foo -- make" would> > return an error because of dependencies missing.>> It took me days to figure out the exact guix environment invocation that> allows me to build the tools for a paper I’m still working on. If that> breaks, that causes massive anxiety, because I then don’t know whether> I’ll find the time to fix it before I run into deadlines.
Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?

Toggle quote (9 lines)> > Other said, I do not see myself use-cases where the scripts using> > "guix environment" need to be robust for time-travelling -- the same> > script used with current, past and future Guix versions -- because as> > it was said elsewhere: "environment" can be seen like "temporary> > profile". And temporary means... well temporary. ;-)>> The same script must always work with future versions. Otherwise the> software is volatile.
Here is the real argument.
It is a point of view. I would like to ear the one of others.If I understand well, Konrad agrees with you.
I am fine with: the same script must always work with future versions.
It is a strong statement and if the Guix project agrees then it mustbe documented. For example in this section [1].
What do you think?

[1] http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-Guix-Way.html#Managing-Software-the-Guix-Way

Toggle quote (3 lines)> You don’t need to be able to go back in time, but the path forward must> be without breakage.
Talking about Reproducible Science, going back in time is the coreissue. If one is able to go back in time and to run again the (almost)exact same version, then the future is not the issue.
Correct me if I misunderstand your point.Today, I write a script using X tools at time T. In the future, I wantto re-run this script so all the X tools must have a path forwardwithout any breakage. It is your point, right? But this never happens,there is always a breakage somewhere; and generally for good reasons.Instead in this future, if I am able to restore the exact same X toolsas they were at time T, my script still works.
Well, this is another story.


Toggle quote (6 lines)> > Last, "volatile" vs "stable" is mitigated by "The future of 'guix> > environment'" [1] which really predates the 1.0. ;-)>> Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,> but it wasn’t.
So if the version bump, it is not an issue then, isn't it?

Toggle quote (8 lines)> >> Also: Software developers should avoid traumatic changes> >> https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html> >> > "Traumatic changes"? Maybe a bit extreme for the change we are talking about...>> I don’t think so. There’s the strong version where it’s obvious: It> leads people to leave a project instantly.
Yes, me!

Toggle quote (4 lines)> There’s the weaker version which is less obvious: That’s where people> who invested efford to follow best practices suddenly find their project> to be written in legacy style, because the best practices changed.
Best practise depends on a lot of parameters. I did not know it was frozen.


Well, I withdraw my investment. I am not interested anymore to nottell that I am traumatized.

Regards,simon
Z
Z
zimoun wrote on 19 Dec 2019 23:48
Re: Deprecating ‘guix environment’?
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ0chDu8M4VNn_Xuq55gZYO+oZdLoNT0_Ly-AimKJvrCrg@mail.gmail.com
On Thu, 19 Dec 2019 at 17:31, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (3 lines)> The hard question then becomes: what do we call it? I vote against> abbreviations. :-)
"guix shell"?


Cheers,simon
A
A
Arne Babenhauserheide wrote on 20 Dec 2019 02:37
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . zimoun)(address . zimon.toutoune@gmail.com)
87zhfn3hgj.fsf@web.de
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (2 lines)> First, have you read the proposal?
Yes.
Toggle quote (2 lines)> Or are you (maybe a bit) "overreacting" about the backward compatibility?
I don’t think so. I am definitely reacting strongly, but that’s becausebreakages in Guix have already cost me the evenings of several weeksthis year.
But before I write anything more, I’d like to ask you to take a stepback to breathe.
We’re discussing a change in software. We disagree on the way forward,but I’m not attacking you as a person, and I hope it does not feel thatway to you.
If it does: This is not my intention. Please take a moment to sighdeeply, shake your head, relax, and smile — because that actually helps.It’s what I try to do when discussions get vexing.
I am grateful that you’re taking up improvements in Guix, and there aresituations where viewpoints are different. That is OK.
Toggle quote (7 lines)>> This is taking this a bit too easy. If I can no longer pull, because>> that breaks my Emacs or Gnome, then Guix is broken for me: I can no>> longer update my system without first adjusting my config.>> So you expect that we would push a patch changing "guix environment"> and in the same time break "guix pull, isn't it?
No, this is an example which shows that being able to roll back does notmean that there is no problem with breaking the way forward. Using onlyold versions is often not an option. Just imagine running audio softwarefrom 5 years ago on a system that only provides pulseaudio (or whateverwill come after it). Imagine using an old KDE DCOP-based automationworkflow on a dbus-system. You need to update the libraries you use toget it working at all.
Toggle quote (10 lines)>> > Hum? I am not convinced that the cost would be high... Because 1. the>> > number of people using Guix is not so high (yet!), so 2. I am almost>> > sure we can name the people using "guix environment" in scripts ;-).>>>> I’m not so sure. Guix is already used in scientific workflows, and there>> is existing third-party documentation about using `guix environment`.>> Please point me where.> It will save me time instead of reinventing the wheel.
It was mentioned on this list.
For the scientific workflows, see https://hpc.guix.info/
Toggle quote (9 lines)>> And can you name the people using `guix environment` by searching>> backwards in their bash history?>> So what would break?> Your workflow: spending 5 minutes to read the warning message and then pressing:> C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment <your-complicated-invokation>>> (unfair and bitter; sorry!)
I’m sorry that this makes you bitter. This is not my intention.
I’ll answer without bitterness: The original environment does not spawninstantly. It takes many minutes until it is ready. If I then have to goback, find the warning (it’s likely that I’d miss it, because these arethings that work, and suddenly they break, which I’m likely to onlyfigure out when the followup steps don’t work) and run it again, thatoften means that I’m out of time to do what I actually wanted to do.
Despite that: Yes, this is a viable way. It is one of the less painfulones. Maybe avoid calling it "DEPRECATED" and instead give it a moredescriptive name that does not imply that it will go away.
Mercurial uses HGPLAIN=1 to say "I want the version which will neverchange established API". Best practice is to always use that in scripts— and that is a stable best practice. But this is also slow to receivenew features.
If the old way to use guix environment is intended to actually be legacyonly, then it could be a way forward to also provideGUIX_ENVIRONMENT_STABLE=1 which gives an API that is guaranteed to neverchange the meaning of options again *after the change that’s beenstarted to brew in 2017*.
That would be a purely append-only API then, and while it would breakonce, it would prevent such changes for the future.
For PR it might be possible to state that with this change, guixenvironment as a tool reaches version 0.99 (to be updated to 1.0 aftersufficient testing).
Toggle quote (11 lines)>> > And 3. the time to figure out what changed is really low -- especially>> > with warnings and hints -- and "guix environment foo -- make" would>> > return an error because of dependencies missing.>>>> It took me days to figure out the exact guix environment invocation that>> allows me to build the tools for a paper I’m still working on. If that>> breaks, that causes massive anxiety, because I then don’t know whether>> I’ll find the time to fix it before I run into deadlines.>> Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?
Yes, at every script. And remember to add it to every command I stillhave in history.
Toggle quote (21 lines)>> > Other said, I do not see myself use-cases where the scripts using>> > "guix environment" need to be robust for time-travelling -- the same>> > script used with current, past and future Guix versions -- because as>> > it was said elsewhere: "environment" can be seen like "temporary>> > profile". And temporary means... well temporary. ;-)>>>> The same script must always work with future versions. Otherwise the>> software is volatile.>> Here is the real argument.>> It is a point of view. I would like to ear the one of others.> If I understand well, Konrad agrees with you.>> I am fine with: the same script must always work with future versions.>> It is a strong statement and if the Guix project agrees then it must> be documented. For example in this section [1].>> What do you think?
Only if this is actually the stance of the whole Guix project.
Currently this is the argument given by one person in an emaildiscussion. I think that it is a strong and important argument(otherwise I would not have made it), but I’ve been wrong before.
Maybe the change to Guix environment now is for the best of the project.I cannot actually see so clearly into the future that I could saywhether the churn due to the breaking change or the annoyance due tosuboptimal default behavior will be worse.
Toggle quote (10 lines)> [1] http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-Guix-Way.html#Managing-Software-the-Guix-Way>>>> You don’t need to be able to go back in time, but the path forward must>> be without breakage.>> Talking about Reproducible Science, going back in time is the core> issue. If one is able to go back in time and to run again the (almost)> exact same version, then the future is not the issue.
The future is an issue, because you often have to use up-to-datelibraries. Just imagine using a rust-tool but being stuck in a 12 monthsold environment that you cannot update without breakage.
Toggle quote (6 lines)> Correct me if I misunderstand your point.> Today, I write a script using X tools at time T. In the future, I want> to re-run this script so all the X tools must have a path forward> without any breakage. It is your point, right? But this never happens,> there is always a breakage somewhere; and generally for good reasons.
No, and that’s the point. That’s also the point of the article: Thereare tools which almost never break. And there are tools that almostalways break.
If you use a tool out of the latter group, you’re in for a world ofpain. It’s why it took years and years for somewhat stable git-wrappersto appear: The early wrappers that made git easier to use always brokewhen git changed operation. Guix environment might actually help youdelay the update until you have time to deal with the breakage.
Toggle quote (5 lines)> Instead in this future, if I am able to restore the exact same X tools> as they were at time T, my script still works.>> Well, this is another story.
This helps surviving volatility in other tools, but only if tool fordoing so isn’t volatile itself.
Toggle quote (8 lines)>> > Last, "volatile" vs "stable" is mitigated by "The future of 'guix>> > environment'" [1] which really predates the 1.0. ;-)>>>> Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,>> but it wasn’t.>> So if the version bump, it is not an issue then, isn't it?
It would still be an issue, but see the part about seeing into thefuture above :-)
Toggle quote (10 lines)>> >> Also: Software developers should avoid traumatic changes>> >> https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html>> >>> > "Traumatic changes"? Maybe a bit extreme for the change we are talking about...>>>> I don’t think so. There’s the strong version where it’s obvious: It>> leads people to leave a project instantly.>> Yes, me!
Have a look at your reaction here. This is just the kind of reactionpeople feel when something into which they invested time suddenly stopsworking as expected.
Toggle quote (6 lines)>> There’s the weaker version which is less obvious: That’s where people>> who invested efford to follow best practices suddenly find their project>> to be written in legacy style, because the best practices changed.>> Best practise depends on a lot of parameters. I did not know it was frozen.
If you manage to freeze the best practices without blocking ways intothe future, then you found part of the holy grail of softwaredevelopment: You managed to find one fragment that’s so good that itnever needs to change again and everything new you do fits to it.
Typically reality isn’t quite as beautiful and change can break yourmodel. They say about Lisp that it’s a snowball: You can keep addingstuff to it and it always stays a snowball. That’s close to this beauty.But Lisp is also full of car/cdr-namings and legacy you cannot shed,even though you might want to.
You cannot reach-and-keep perfection in a changing world, you can onlytry to limit the pain for users and stay close to something which feelsright.
Volatile projects do not work to limit the pain.
Stale projects do not try to stay close to ways that feel right in achanging reality.
A good project needs to get as close as possible to a consensus (I’m notsaying compromise here, because that’s not what I mean — the goal issomething which unites both) between not being volatile and not becomingstale.
Best wishes,Arne--Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl38Jd8ACgkQE++NRSQDw+vC8g/8CTt/lgrSap1zl00qvgCOBd3OIiabwzGWWP47FW/pQhQbhQ9Pq6+qs9Rv2e5SOcPsA208rOz5acQrrEdzlj3XjM/1WFTmDtyu8mA7ROypQktV5Djy3oTGPPiNWEScyzIAOsLI07rhineOr950JXlStuS2aN6gBUshbGThPBG4Qz+zLgBZ6F3/QPEb2XKFMkeGS2dDBmWk/F9u4/liC6WWP7RPl1jZLUC5pxVRZvqUNnjM2TXeBmlv3ItGLzQ5LriOUrZrUVE/xLE1NjjTbLlzzn3yL5yVh8NCt6KoAc9BkOg6yjk671YHaxj2GHFTJHXWvY+sYGAp1+YIj6c1zYPfadMmbPx3SwftLcetv7zUxk4HPVZB9FwToLskGw8ow1M2n5XBurufkpa2UzJ7leJSP+PH++EU0u8+hbTbpKwTNtkrlPmdPdk17lWpuzumBs33Fzbzo7nBdkM7keTsqepNusq0KlLUmLQNJCYqYtELxsPSvYguFkr6XBzdmp95vYi37V0rWLsrUW6xx8wYTz9WAYUgki2DKvD5ZuTdSO9AHCup5zTjIDdE+KV+mgfSuKegHLa3yTUE1Z/C25GFicSyHLIU9seYs6cac8Hvv9MziD00osd8meCU+w0QfDV1xhQ9NRrkcKGtDTnAuosBkoA7EfMDRIbJ0245tGBUr3fVK82IswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd/CXfAAoJENzPDbMLwQVIVb4D/3ZHXk97aeV6d0bwuvAic/Rbjg08RAx2gP4IOopHI+/TWL0O7dCv1OW6jDAW5k36iAGaJhD06lIrUPH+LvCbpI2buacb1O0PO13BLUAVLkFoteLRMJiaiM8Juvoz/W87mNkDEsVBGgtf5r3qKTGur+I8jnY5bavuGCEjTDKfk1Xh=VZF0-----END PGP SIGNATURE-----
K
K
Konrad Hinsen wrote on 20 Dec 2019 12:17
Re: Deprecating ‘guix environment’?
(name . Ludovic Courtès)(address . ludo@gnu.org)
m1immbz1ny.fsf@ordinateur-de-catherine--konrad.home
Hi Ludo,
Toggle quote (2 lines)> Clearly there’s a tension between that and keeping Guix open to changes.
That's indeed the main problem and here as elsewhere, it is often atopic of heated arguments.
My point of view (long form:https://hal.archives-ouvertes.fr/hal-02117588)is that software projects should adopt a backwards compatibility policyearly on, state it clearly in their documentation, and stick to it. Thatprevents misunderstandings, bad surprises, and heated debates.
As for what that policy should be for Guix, that's a more difficultstory. For projects with versioned releases, I like the principlesof semantic versioning, but Guix is more of a rolling-releaseproject. (Test question: does anyone know what the current Guix versionnumber is? Does anyone care?) I am not aware of any good precedentsin terms of policy for such projects.
Toggle quote (6 lines)> 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?
I vote for discussing the second point before the first one. Namesshould reflect the functionality behind them.
How about a unified command for constructing environments and profilesdeclaratively? In other words, combine "guix environment" and thedeclarative parts of "guix package". We could probably get rid ofthe somewhat obscure "guix environment -r" in the process.
Cheers, Konrad.
K
K
Konrad Hinsen wrote on 20 Dec 2019 12:24
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . zimoun)(address . zimon.toutoune@gmail.com)
m1fthfz1db.fsf@ordinateur-de-catherine--konrad.home
Hi Simon,
Toggle quote (5 lines)> Assuming "guix environment" would stay and following the proposed> plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top> of your script. In this would not be a problem for travelling back in> time.
The problem is not how I update my scripts - I can manage that, nomatter what it takes.
The problem is scripts circulating in public repositories, tutorials,etc. New users will find them and use them for inspiration. It's verydiscouraging to see examples from tutorials fail or do something weird.
The main precedent is the Python 2->3 transition. There are tons ofGitHub repositories with Python code but no indication if it's 2, 3, orboth. I even had to use one that executed with either 2 or 3, but gavedifferent results. It takes a lot of motivation to persist.
For guix, there's the additional issue that we use the reproducibilityof builds as an argument. Non-reproducible examples are then a bit of acredibility problem.
Cheers, Konrad.
Z
Z
zimoun wrote on 20 Dec 2019 12:40
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
CAJ3okZ2XTAbPp0m7TQqCEi_oz223HyBd0BZefRO4Q90xmni2mw@mail.gmail.com
Hi Arne,

On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide <arne_bab@web.de> wrote:
Toggle quote (21 lines)> > Or are you (maybe a bit) "overreacting" about the backward compatibility?>> I don’t think so. I am definitely reacting strongly, but that’s because> breakages in Guix have already cost me the evenings of several weeks> this year.>> But before I write anything more, I’d like to ask you to take a step> back to breathe.>> We’re discussing a change in software. We disagree on the way forward,> but I’m not attacking you as a person, and I hope it does not feel that> way to you.>> If it does: This is not my intention. Please take a moment to sigh> deeply, shake your head, relax, and smile — because that actually helps.> It’s what I try to do when discussions get vexing.>> I am grateful that you’re taking up improvements in Guix, and there are> situations where viewpoints are different. That is OK.

I am fine. :-)Life is about managing disagreements.And I am probably a typical grouchy French. ;-)
Well, if we go back in time, the story is: - the original author of "guix environment" is not happy with thecurrent behaviour and proposes a change (see "The future of 'guixenvironment'"). - life happens (v1.0) but not this change. - I am not happy with the current behaviour and other on IRC neither. - a plan to change is opened for discussions.
The first concern by Ludo is about the compatibility.Then Konrad raises concrete examples.
At this point, my personal opinion is: the cost is low so the change can happen.However, I agree with the "backward compatibility" issue and even Ipropose a name for this "new" command: "guix shell".
Then you ask one question: "Should Guix be volatile software?" withthe subtitle "Software developers should avoid traumatic changes".Nothing more.Well, I answer you by trying to fill the gap. Note that "volatilesoftware" is the same argument than the Ludo's concern and theKonrad's example. So, nothing new on the table; except you arestarting to throw "feelings" with the "traumatic change" words.
Then, your following answer is more about your feelings than concreteexamples. It is hard to know in advance how many scripts or use-caseswould be broken -- i.e., estimate the cost -- and a way is to probe;say: "it will break X of my scripts" or "in my institute, X people use"guix environment blabla" daily, so it is not an option", etc.Otherwise, it is unproductive.
Well, instead of arguing about feelings because it is going nowhere orat better a flame war about "backward compatibility", I prefer goingto spend my time elsewhere (still about Guix :-)).I mean, I proposed, I said my opinion and I called to collect moreopinions. I feel I did my best on this front and other fronts deserveproposals and fixes.

Kind regards,simon
ps:Note that I did a proposal which could be a path to reduce the burdenof "guix pull" breakage: adding tags. Feel free to comment.
https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
Z
Z
zimoun wrote on 20 Dec 2019 13:03
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAJ3okZ32Ozgky=qUtj+QwjNRoX6aTzWKrMXy0M0wZpLAZRi8pg@mail.gmail.com
Hi Konrad,
On Fri, 20 Dec 2019 at 12:24, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Toggle quote (4 lines)> The problem is scripts circulating in public repositories, tutorials,> etc. New users will find them and use them for inspiration. It's very> discouraging to see examples from tutorials fail or do something weird.
As I said, I am not convinced because it lacks concrete examples.Personally, I do not know Guix ressource outside the Guix ecosystem.

Toggle quote (5 lines)> The main precedent is the Python 2->3 transition. There are tons of> GitHub repositories with Python code but no indication if it's 2, 3, or> both. I even had to use one that executed with either 2 or 3, but gave> different results. It takes a lot of motivation to persist.
Except that "guix environment" will raise warnings.Whatever.

Toggle quote (4 lines)> For guix, there's the additional issue that we use the reproducibility> of builds as an argument. Non-reproducible examples are then a bit of a> credibility problem.
I agree.I do not want to fight about "backward compatibility".

As I said, talking about "guix environment", my opinion is that thecost of the change is low.However, we cannot know this cost, only probe and estimate: using myprobings, I estimate the cost is low.
IMHO, in this case, there is 2 ways to make a decision: - more probings to estimate more precisely;or - say: "no backward compatibility breakage"
I am fine with both. :-) - I report my use-case: no cost at all - I propose the name "guix shell"

However, I feel I have spent enough time and energy on this topic andI feel a blocking situation so I will move forward to another topic.:-)
All the best,simon
Z
Z
zimoun wrote on 20 Dec 2019 14:21
Re: Deprecating ‘guix environment’?
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
CAJ3okZ1paGtBzEGQZOn2U5Y4chTtR+MxK7PkAT1i_4orSHdOMA@mail.gmail.com
Hi Konrad,

On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Toggle quote (6 lines)> My point of view (long form:> https://hal.archives-ouvertes.fr/hal-02117588)> is that software projects should adopt a backwards compatibility policy> early on, state it clearly in their documentation, and stick to it. That> prevents misunderstandings, bad surprises, and heated debates.
Thank you for the pointer. I have not read yet.I agree with the compatibility policy and this argument has beenraises in the "heated" debate with Arne. :-)

Toggle quote (3 lines)> As for what that policy should be for Guix, that's a more difficult> story. For projects with versioned releases, I like the principles
The first idea which comes in mind is to introduce a pledge. Maybe inthe introduction.
"The Guix project pledges to keep backward compatibility... blabla".
However, the real question is at which level.At the CLI level? At the exported scheme functions? All modules orspecific ones?

Toggle quote (5 lines)> of semantic versioning, but Guix is more of a rolling-release> project. (Test question: does anyone know what the current Guix version> number is? Does anyone care?) I am not aware of any good precedents> in terms of policy for such projects.
I agree.
I proposed [1] to add "tags" in the meaning of "git tag". Initially,to ease the navigation through the history when searching forpackages.Re-hashing this "guix tag" or "guix pull --tag" proposal, one ideacould be to introduce tags, say v1.1, v1.2, v1.3 etc bumping theversion every X months, or after each core-update merge, or after<you-name-it>, then by default "guix pull" would update to the tags.This adds "stability" because we could tag commits that we know arestable (no "guix pull" break, etc.)
[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html

Toggle quote (9 lines)> > 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?>> I vote for discussing the second point before the first one. Names> should reflect the functionality behind them.
The starting point seems: - https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html - what do you feel missing about "guix environment"?
Considering my use-case, I am mostly aligned with "The future of 'guixenvironment'".


All the best,simon
R
R
Ricardo Wurmus wrote on 20 Dec 2019 22:08
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . zimoun)(address . zimon.toutoune@gmail.com)
87woaqpuvz.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (2 lines)> - I propose the name "guix shell"
This is not a bad idea, especially considering that “guix environment”was meant to get shebang support, so that you could use it as theinterpreter in a script that handles the environment configuration.
It is also shorter.
--Ricardo
R
R
Ricardo Wurmus wrote on 20 Dec 2019 22:12
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)
87v9qapuq6.fsf@elephly.net
Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
Toggle quote (9 lines)>> Maybe I miss a point. It is not: "watch out, this will do something>> else in the future" but "watch out, this was doing something else in>> the past and the change happened the <date> in <commit>".>> Concrete example: I am writing a tutorial about using Guix for> reproducible research. It shows several uses of "guix environment", some> of them without '–add-hoc' or '–inputs-of'. I know my examples will> cease to work in a few months. What am I supposed to do about this?
I wonder if we should simply bump the version number to indicate thatthis is a breaking change?
Another more difficult option would be to do what responsible APIdevelopers on the web do: to version their API and to make the APIversion selectable. I don’t know *how* to do this elegantly, andthere’s a real maintenance cost (it seems small in this case), butconfiguration files can be used for changing new defaults.
--Ricardo
R
R
Ricardo Wurmus wrote on 20 Dec 2019 22:31
(name . zimoun)(address . zimon.toutoune@gmail.com)
87tv5upttv.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (8 lines)> Then you ask one question: "Should Guix be volatile software?" with> the subtitle "Software developers should avoid traumatic changes".> Nothing more.> Well, I answer you by trying to fill the gap. Note that "volatile> software" is the same argument than the Ludo's concern and the> Konrad's example. So, nothing new on the table; except you are> starting to throw "feelings" with the "traumatic change" words.
I’m just chiming in here to say that feelings of frustration are veryvalid reasons to make or object to a change. Guix is or can be a veryimportant piece of software — if it remains reliable in the toolbox ofthose using it.
It is difficult striking the right balance between exciting new featuresthat make things possible that were previously unattainable anddependability through stable interfaces.
The Guix command line is by far the most commonly used interface. Wecan’t just claim that the Scheme API is stable (which it actually isn’t)and change the user-facing CLI as we please.
Personally, I think that it is fine to introduce breaking changes, butthat for changes that are likely to have a high potential for annoyanceand frustration there ought to be a documented way to work around them.Breaking changes must be communicated through version number bumps andaccompanying announcements.
While I don’t see how we can make it happen, I do find the idea of astable API whose version can be selected with an environment variableintriguing and worth thinking about. If our Scheme API is as flexibleas we claim it shouldn’t be too hard to interpose a configuration layerbetween the core facilities and the “porcelain”.
I wonder what the other maintainers think about this.
--Ricardo
A
A
Arne Babenhauserheide wrote on 21 Dec 2019 00:02
(name . zimoun)(address . zimon.toutoune@gmail.com)
87o8w2iorn.fsf@web.de
Hi zimoun,
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (3 lines)> Konrad's example. So, nothing new on the table; except you are> starting to throw "feelings" with the "traumatic change" words.
I do not see this as feelings, but as strategy. That’s what the articleis about: Many small breakages add up, and repeated changes tobest-practices also add up.
The volatile software article describes that software differs in howmuch work it is to keep using it. The traumatic change article discussesone aspect why people stop using projects.
Best wishes,Arne--Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl39Ux8ACgkQE++NRSQDw+vYUhAAklXBpD4PXyigANFXMLGMqdMC3eQYrD5QO5hKDTvhlEDefIrSCsRbq/ti5boMWnIcUli5Gks4QdQ2DMrePmRKbyK8z/uL7BNOz6BlVIIKgwcwypfbzXZCV7MjO5dZPqPA5hM0hwRABhEkQsz5/hjX5UoW4Uy2jLh7+EfGg0ITCv+5mUaWFbPQwyWhvbRm3NWMTt/FIbeOwaHMLmBiCrB4vzRTb6GsZ+tPbAKoEq7csqMOZ0leMzjWclPmgnFZtX9kQeeDOevKVAQ7jJHzkypygE9wycJ7ZIK9rRVr90/biekwGRzDWlvjwxrY3VxzF8a9RDGRM0t3hRVe4GF9Ngf9TmX5LDoEY/EmIj1V+ZTZYhYi1fRDD5AGNz8LPapgE6SDQVYaVnoxX1HROt2I0VLEjbZqHzhj2iVC0gU5cCpfHanVDFKtkARiYiejU6B1S/JHOzPhA7d9rzxghAC+5zACNYmHLYASCY+5TfIC5Xcin+2wGXXmTiJHZgMgr6ZSsc8sBaQ3FrnIX00MLVa2JxeWPznK7RyuyBzwKEn6zYK7VjnKBS61tLYnj5tbjo+Np/SbT/4f30LC9P9rUzLXQzmqwFsviFWOiDcAOHf+75k2LjO3/h3nz25RuILni0Ub7Nd5dKIPp+eoBxtJch6AMIFYa8vgThHxy2zIbAt7a2DGaWKIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd/VMfAAoJENzPDbMLwQVIM64EAIFu1nUhvkoVT7CR6fMYGl76dwqrNi5TkhO9kX6mXZfhkgcnW+O6+2lWCjGCuSIICSFE5/uZUjzZv8J2RyhwgP6s3mQ/fckTvS03vt94ESnnmBuhnT2huTXlKu6nyJX1lUN/fAQn5K1Fc9ZkWzyWbCspwJZWkRGTMQFBtkhJ+pCc=CGQ6-----END PGP SIGNATURE-----
Z
Z
zimoun wrote on 21 Dec 2019 01:04
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
CAJ3okZ071vtMPF_xsdg6wPkP7KUqE9szrDDc8_s0EVg_BDPJzA@mail.gmail.com
Hi Arne,
First, do not take me wrong, I am not "fighting" or not going to an"heated debate".I am fine and I hope you are also fine.As I said my opinion in other emails, I am not repeating here. Well, Iam not convinced it is the good one, but as I trust collective power,I am sure Guix will find the best consensus. I am even calling sincethe very beginning of this discussion to collect opinions from theother fellow hackers.

Expressing the feelings is better than bitterness. Therefore I expressmines. :-)I could send that privately because I am not sure it deserves to bepublic. But let wash the laundry in family (translation from Frenchexpression ;-))

On Sat, 21 Dec 2019 at 00:02, Arne Babenhauserheide <arne_bab@web.de> wrote:
Toggle quote (7 lines)> > Konrad's example. So, nothing new on the table; except you are> > starting to throw "feelings" with the "traumatic change" words.>> I do not see this as feelings, but as strategy. That’s what the article> is about: Many small breakages add up, and repeated changes to> best-practices also add up.
Just to be on the same wavelength, traumatic means in the CollinsDictionnary: "A 'traumatic' experience is very shocking and upsetting,and may cause psychological damage."
https://www.collinsdictionary.com/dictionary/english/traumatic
Well, to me it could make sense in the context of the mentioned blog.Even if I feel this very opinionated. Not to say it could hurt me; bahI am a big boy, that's ok.
Again, to be on the same wavelength, the blog says: "The result hasbeen hugely divisive and intimately familiar to anyone who works withPython, creating massive rifts in the community and wasting millionsof hours of engineer time addressing. This kind of “strong” trauma isfairly easy to spot in advance."
Well, I understand when speaking about Python. Are we comparing thenumber of Guix users with the number of Python users? Are we comparingthe number of changes between Python 2 and 3 with the change of thedefault "guix environment foo"? And not all the "guix environment"behaviour, only a specific case.
Ok, maybe we are talking about the other trauma. The blog explains:"Since nothing has actually broken with this change, the effects aremore subtle than with strong traumatic changes." and then "Theopportunity to solve this problem by rewriting with asyncio in mind,however, also presents me a chance to rewrite in anything else, andreevaluate my choice of Python for the project entirely."
I am sorry, I do not understand. I am probably too dumb. On one hand,the issue of "guix environment" is the very backward compatibility soare we really talking about this second "trauma"? On the other hand,because "guix environment" will be better and users probably need torethink how they use Guix, then they will fully drop Guix.

Maybe "feelings" (quoting, in citation quoted too) is not the rightword. My point is all is vague. Example: I have the feeling that mystudents(*) do not like Scheme; do I need to switch next year toanother language? Then do I make my decision based on my feelings?based on the feelings of the students who are retaking the year (couldbe shocked)? Me, I will make my decision based on: how many studentsfailed? what do they understand? what could be better for all thestudents? what could be a better language? what is the ratio betweenthe new student vs the retaking ones? how many length the Schemetextbook is? etc. Well, analogy is just analogy.

Well, that's it. I expressed what it appears to me a trail goingnowhere. Let move forward and put energy in "backward compatibility"discussion: does Guix want? what does it imply? which level? etc. forexample, your interesting input "GUIX_ENVIRONMENT_STABLE=1".
All the best,simon
(*) hypothetical, I do not have real students, even if I teach a bit.And we use Python as introduction to implemented algorithms after 1year fighting to switch from C. Whatever! :-)
G
G
Gábor Boskovits wrote on 21 Dec 2019 09:40
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAE4v=pjJMc3YPft5SOeSZQAeAUsf2mnFKWiGvcSG3o_i9NV3yQ@mail.gmail.com
Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2019. dec. 20., Pén22:32):
Toggle quote (36 lines)>> zimoun <zimon.toutoune@gmail.com> writes:>> > Then you ask one question: "Should Guix be volatile software?" with> > the subtitle "Software developers should avoid traumatic changes".> > Nothing more.> > Well, I answer you by trying to fill the gap. Note that "volatile> > software" is the same argument than the Ludo's concern and the> > Konrad's example. So, nothing new on the table; except you are> > starting to throw "feelings" with the "traumatic change" words.>> I’m just chiming in here to say that feelings of frustration are very> valid reasons to make or object to a change. Guix is or can be a very> important piece of software — if it remains reliable in the toolbox of> those using it.>> It is difficult striking the right balance between exciting new features> that make things possible that were previously unattainable and> dependability through stable interfaces.>> The Guix command line is by far the most commonly used interface. We> can’t just claim that the Scheme API is stable (which it actually isn’t)> and change the user-facing CLI as we please.>> Personally, I think that it is fine to introduce breaking changes, but> that for changes that are likely to have a high potential for annoyance> and frustration there ought to be a documented way to work around them.> Breaking changes must be communicated through version number bumps and> accompanying announcements.>> While I don’t see how we can make it happen, I do find the idea of a> stable API whose version can be selected with an environment variable> intriguing and worth thinking about. If our Scheme API is as flexible> as we claim it shouldn’t be too hard to interpose a configuration layer> between the core facilities and the “porcelain”.>
This is something that needs consideration. I believe that the originalideas presented here, and what you say about having a stable api can beeasily synchronized by naming the environment variable to something likeGUIX_CLI_API_VERSION. I would propose it to be of the form 1.0.1.0, so thatthe first three numbers could be the current guix version. Havin it thisway would allow inter releas updates bumping the last number, and theability to easily set a new default when the major version is bumped, whichimplies a breaking change anyways. From there on the question would be whatshould be the default? I would say, that is should be<current-mayor>.0.0.0. Does that make sense? Maybe we could come up withsomething simpler, like dropping the second and third number.
Toggle quote (10 lines)>> I wonder what the other maintainers think about this.>> --> Ricardo>>>>>
Attachment: file
K
K
Konrad Hinsen wrote on 21 Dec 2019 16:18
(name . Ricardo Wurmus)(address . rekado@elephly.net)
m1sgldyaey.fsf@ordinateur-de-catherine--konrad.home
Hi Ricardo,
Toggle quote (3 lines)> I wonder if we should simply bump the version number to indicate that> this is a breaking change?
That's a possibility, but who ever looks at Guix version numbers?
Toggle quote (4 lines)> Another more difficult option would be to do what responsible API> developers on the web do: to version their API and to make the API> version selectable. I don’t know *how* to do this elegantly, and
That's an interesting idea which would also take care of similarsituations in the future.
One way to implement this is to have executables "guix1", "guix2"etc. Most users would then define an alias "guix" for interactive use,but hopefully script authors would use the versioned executables.
Cheers, Konrad.
L
L
Ludovic Courtès wrote on 21 Dec 2019 17:51
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87o8w1mxjt.fsf@gnu.org
Hi!
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (13 lines)> I’m just chiming in here to say that feelings of frustration are very> valid reasons to make or object to a change. Guix is or can be a very> important piece of software — if it remains reliable in the toolbox of> those using it.>> It is difficult striking the right balance between exciting new features> that make things possible that were previously unattainable and> dependability through stable interfaces.>> The Guix command line is by far the most commonly used interface. We> can’t just claim that the Scheme API is stable (which it actually isn’t)> and change the user-facing CLI as we please.
Agreed.
Toggle quote (6 lines)> Personally, I think that it is fine to introduce breaking changes, but> that for changes that are likely to have a high potential for annoyance> and frustration there ought to be a documented way to work around them.> Breaking changes must be communicated through version number bumps and> accompanying announcements.
Yes, I think it is clear that we’d have to do this using all the toolsat our disposal, including time.
Konrad’s objection remains though: existing documents (papers, blogposts, MOOCs, etc.) that mention ‘guix environment’ would all of asudden become wrong if we were to change the defaults of ‘guixenvironment’. Even if we introduce a variable to restore the oldbehavior.
Perhaps that’s unavoidable in the long run, but perhaps this is not theright time for this.
Toggle quote (6 lines)> While I don’t see how we can make it happen, I do find the idea of a> stable API whose version can be selected with an environment variable> intriguing and worth thinking about. If our Scheme API is as flexible> as we claim it shouldn’t be too hard to interpose a configuration layer> between the core facilities and the “porcelain”.
You mean a stable Scheme API, or a stable CLI?
To me, a stable CLI is definitely the goal. As for the Scheme API, Iwould distinguish core APIs, peripheral APIs (e.g., the importers), (gnusystem …) APIs, and packages. I’d aim for high stability for core APIs,be laxer for peripheral APIs, even laxer for the remaining.
I’m not sure what you mean about adding a configuration layer betweenthe core facilities (the core Scheme APIs?) and the porcelain?
Thanks,Ludo’.
D
D
Danny Milosavljevic wrote on 23 Dec 2019 10:28
(name . Ricardo Wurmus)(address . rekado@elephly.net)
20191223102800.35e12fea@scratchpost.org
Hi Ricardo,
On Fri, 20 Dec 2019 22:08:48 +0100Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (8 lines)> zimoun <zimon.toutoune@gmail.com> writes:> > > - I propose the name "guix shell" > > This is not a bad idea, especially considering that “guix environment”> was meant to get shebang support, so that you could use it as the> interpreter in a script that handles the environment configuration.
Note that the Linux kernel shebang interpreter only supports ONE argument.The good news is that whatever number of arguments you pass, it will allbe subsumed into the first argument.
#!foo bar baz
foo gets: $1="bar baz", $#=2
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl4AiKAACgkQ5xo1VCwwuqV1gQf7Bn7WDu9gn8Y9GfN1sW1dNR3p0wQjGjGHvBeNpaZ+7iWroOz7ObRXGoT406YudNnN9kxulLzTc12G657YFMLq7q3BsAUX+sbYQkhYOOI5mau9NeaqaTuuI0yv0xmorYN8NdTZ+kY5x17X8KZTGvVIw96cZMgxS+IbbxRxLC3xTxvlxMQ9y72K1A55I4Mrz32lpmJ8GXZMPEMIm0eS14gEqNxktgL81lx2CWs8+oaftMJ6BTNSHHkBVq9ixH49KeEORRVtyBUdQxaNGkH0YYdmPjNMskrsfusBv5KHFJIlSLSH/WaF0tZylgEMWP55Oi+jxyjuLJ2lMFcIFrdSoQYRRA===mzlL-----END PGP SIGNATURE-----

E
E
EuAndreh wrote on 30 Dec 2019 10:44
87blrqp2pp.fsf@euandre.org
Hello :)
Jumping in the discussion xD
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (12 lines)> Yes, I think it is clear that we’d have to do this using all the tools> at our disposal, including time.>> Konrad’s objection remains though: existing documents (papers, blog> posts, MOOCs, etc.) that mention ‘guix environment’ would all of a> sudden become wrong if we were to change the defaults of ‘guix> environment’. Even if we introduce a variable to restore the old> behavior.>> Perhaps that’s unavoidable in the long run, but perhaps this is not the> right time for this.
Wouldn't having a new name for the new behaviour avoid breakage in thissituation?
Suppose the path of adding new subcommand is chosen, and it is "guixshell". Couldn't it adopt the new desired behaviour?
guix shell foo --inputs-of bar # new command guix environment bar --ad-hoc foo # untouched old command
After the introduction of "guix shell", "guix environment" could becomedeprecated, but no current usage of it would stop working, and no publicreferences to it in the internet would become misleading. "guixenvironment" could say that is has been deprecated, and point to "guixshell", but keep working the same way.
If desired, "guix environment" could be removed after X time ofdeprecation has passed, but that would be optional.
What are the downsides? Am I missing something?
Thanks,euandreh.
L
L
Ludovic Courtès wrote on 30 Dec 2019 11:34
(name . EuAndreh)(address . eu@euandre.org)
878smu85kw.fsf@gnu.org
Hi,
EuAndreh <eu@euandre.org> skribis:
Toggle quote (17 lines)> Ludovic Courtès <ludo@gnu.org> writes:>>> Yes, I think it is clear that we’d have to do this using all the tools>> at our disposal, including time.>>>> Konrad’s objection remains though: existing documents (papers, blog>> posts, MOOCs, etc.) that mention ‘guix environment’ would all of a>> sudden become wrong if we were to change the defaults of ‘guix>> environment’. Even if we introduce a variable to restore the old>> behavior.>>>> Perhaps that’s unavoidable in the long run, but perhaps this is not the>> right time for this.>> Wouldn't having a new name for the new behaviour avoid breakage in this> situation?
Yes, that’s correct (that’s also one of the suggestions Konrad made).
We could take that route. What would we call it, though? I don’t like“guix shell” because it doesn’t quite reflect what the command isabout. No good idea, though.
Thanks,Ludo’.
Z
Z
zimoun wrote on 30 Dec 2019 13:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ3jjB8kRRN3xqv7VWn0ba_Qwm8jDWUUiodXi+NtQwWsLA@mail.gmail.com
Hi Ludo,
On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (5 lines)> > Wouldn't having a new name for the new behaviour avoid breakage in this> > situation?>> Yes, that’s correct (that’s also one of the suggestions Konrad made).
Is this statement acted? Is it the consensus by all the maintainers?
And I am not clear about what will happens for "guix environment"?Deprecate for sure.But after X time: removed or frozen?
Removing the command "guix environment" is against the backwardcompatibility argument because all the current documentation/scriptsusing it will not work anymore. Other said, if thedocumentation/scripts cannot be updated as it was said -- in favor forstrong backward compatibility -- then the user will be surprised thatwhat worked does not anymore because the command does not existanymore.
Therefore, if Guix goes the backward compatibility route, then the"guix environment" should be frozen until the version 2.0 and so onlyremoved when the 2.0 will be released. Or I misunderstand thearguments in favor of the backward compatibility.
As Arne described the process (bottom of [1]), "guix environment" willbecome a kind-of alias of "guix shell/<name-it>". Right?


Toggle quote (4 lines)> We could take that route. What would we call it, though? I don’t like> “guix shell” because it doesn’t quite reflect what the command is> about. No good idea, though.
Argh! Naming is hard.Something that reflects what the command is about: "guix environment"?(joke!! ;-))
Why do you say that "guix shell" does not reflect what the command is about?Because the command spawns a new shell with options (expanding it,isolating it, etc.)
Well, because we do not seem having good idea for a new name, maybe ifwe argument why we collectively find that name or this name is bad orgood, one of us will find the good name. Currently, "guix shell" seemsthe better option.

All the best,simon
L
L
Ludovic Courtès wrote on 30 Dec 2019 16:06
(name . zimoun)(address . zimon.toutoune@gmail.com)
87tv5h7t0j.fsf@gnu.org
Hello!
zimoun <zimon.toutoune@gmail.com> skribis:
Toggle quote (9 lines)> On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès <ludo@gnu.org> wrote:>>> > Wouldn't having a new name for the new behaviour avoid breakage in this>> > situation?>>>> Yes, that’s correct (that’s also one of the suggestions Konrad made).>> Is this statement acted? Is it the consensus by all the maintainers?
All I’m saying is that what EuAndreh wrote above is correct; I’m notstating anything as to what solution we should implement. :-)
Toggle quote (4 lines)> And I am not clear about what will happens for "guix environment"?> Deprecate for sure.> But after X time: removed or frozen?
I guess that’s the whole point of deprecation.
Toggle quote (3 lines)> As Arne described the process (bottom of [1]), "guix environment" will> become a kind-of alias of "guix shell/<name-it>". Right?
Yes.
Toggle quote (8 lines)>> We could take that route. What would we call it, though? I don’t like>> “guix shell” because it doesn’t quite reflect what the command is>> about. No good idea, though.>> Argh! Naming is hard.> Something that reflects what the command is about: "guix environment"?> (joke!! ;-))
Yeah!
Toggle quote (4 lines)> Why do you say that "guix shell" does not reflect what the command is about?> Because the command spawns a new shell with options (expanding it,> isolating it, etc.)
The command does not necessarily spawn a new shell; it spawns a commandin a well-defined environment, and that command might be a shell.
Thanks,Ludo’.
R
R
raingloom wrote on 30 Dec 2019 18:27
Re: bug#38529: Make --pure the default for `guix environment'?
0eda3cfa6b08d9e58249eac6d41df0c0af33f681.camel@riseup.net
On Tue, 2019-12-10 at 18:16 +0100, Ludovic Courtès wrote:
Toggle quote (12 lines)> As for ‘--ad-hoc’: making it the default is technically easy. The> difficulty is to come up with a nice transition/deprecation mechanism> so> that we don’t break everyone’s script overnight.> > Ideas on how to achieve it are welcome!> > Thanks,> Ludo’.> >
Why not make it fully explicit, without either being the default?It would make script more readable too.
Then the deprecation is as easy as printing a warning when theinvocation relies on the default.
For example `guix environment hello` would become `guix environment --inputs-of hello`. Not using `--inputs-of` would print something like"warning: implicit --inputs-of is deprecated".
Z
Z
zimoun wrote on 30 Dec 2019 18:55
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ2WVmPprrGw4xnzpRYzBeMXMPVnaTgG00=DicTaRFRMmw@mail.gmail.com
Hey!
On Mon, 30 Dec 2019 at 16:06, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (8 lines)> zimoun <zimon.toutoune@gmail.com> skribis:> > On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès <ludo@gnu.org> wrote:
> > Is this statement acted? Is it the consensus by all the maintainers?>> All I’m saying is that what EuAndreh wrote above is correct; I’m not> stating anything as to what solution we should implement. :-)
Héhé, it is an answer to the questions. ;-)

Toggle quote (7 lines)> > Why do you say that "guix shell" does not reflect what the command is about?> > Because the command spawns a new shell with options (expanding it,> > isolating it, etc.)>> The command does not necessarily spawn a new shell; it spawns a command> in a well-defined environment, and that command might be a shell.
What about "guix spawn"?
All the best,simon
R
R
Ricardo Wurmus wrote on 30 Dec 2019 22:10
(name . zimoun)(address . zimon.toutoune@gmail.com)
87eewlo6yp.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (9 lines)>> > Why do you say that "guix shell" does not reflect what the command is about?>> > Because the command spawns a new shell with options (expanding it,>> > isolating it, etc.)>>>> The command does not necessarily spawn a new shell; it spawns a command>> in a well-defined environment, and that command might be a shell.>> What about "guix spawn"?
“spawn” is a very generic verb, much like “enter” (enter what?) or“make”. “shell” has the awkward property of meaning different thingsdependent on how you interpret it: “to shell” means to *remove* an outershell (like that of a nut) whereas “guix shell” as a noun would imply*wrapping“ something in a shell. It sends mixed signals. We’d probablywant people to understand it as ‘spawn a command line shell’, but that’sreally not the primary purpose of ‘guix environment’.
Thinking about words some more I started to wonder: do we want verbs ornouns? We have some sub-commands that could be interpreted either way:
archive gc hash
Others that are primarily understood as nouns:
container environment graph package processes repl size system time-machine weather
And a majority that are primarily understood as verbs:
build challenge copy deploy describe download edit import install lint pack publish pull refresh remove search show upgrade
If we were looking for verbs that express the idea of creating anenvironment or to place a thing inside of an environment we could useone of these:
to envelop (envelop what though? This seems to require two objects.) to arrange (kinda misses the point) to stage (in the theatric sense) to frame (not in the criminal sense) to contain (…the resulting process in a possibly leaky environment) to join (…all these packages to form a new whole) to group (…all these packages)
(As a bonus: ‘to environ’ exists, but it suffers from the same problemas ‘to envelop’.)
Here are some nouns that might work:
scene frame context union
All of them are shorter than “environment”! :)What do you think?
--Ricardo
Z
Z
zimoun wrote on 30 Dec 2019 22:32
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ1+m-6AM=vs=62EE88TeTqm41vZ8KfwYQYo+MWTmxn66w@mail.gmail.com
Hi Ricardo,
Thank you for your input.
On Mon, 30 Dec 2019 at 22:10, Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (7 lines)> zimoun <zimon.toutoune@gmail.com> writes:
> > What about "guix spawn"?>> “spawn” is a very generic verb, much like “enter” (enter what?) or> “make”.
My English is not good enough to see the drawback. :-)

Well, my personal flavor is:
Toggle quote (6 lines)> to contain (…the resulting process in a possibly leaky environment)> to join (…all these packages to form a new whole)> context> union

All the best,simon
L
L
Ludovic Courtès wrote on 31 Dec 2019 19:09
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87tv5gxt7x.fsf@gnu.org
Hi!
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (2 lines)> zimoun <zimon.toutoune@gmail.com> writes:
[...]
Toggle quote (10 lines)>> What about "guix spawn"?>> “spawn” is a very generic verb, much like “enter” (enter what?) or> “make”. “shell” has the awkward property of meaning different things> dependent on how you interpret it: “to shell” means to *remove* an outer> shell (like that of a nut) whereas “guix shell” as a noun would imply> *wrapping“ something in a shell. It sends mixed signals. We’d probably> want people to understand it as ‘spawn a command line shell’, but that’s> really not the primary purpose of ‘guix environment’.
Yeah.
Toggle quote (3 lines)> Thinking about words some more I started to wonder: do we want verbs or> nouns?
I think verbs are preferred, but nouns are accepted. :-)
For example, ‘time-machine’ was recently introduced, but I find it nicethat way; ’travel-in-time’ wouldn’t be better.
It’s much like Scheme APIs: we use nouns for object properties (like‘commit-parent’) and verbs for things that are best viewed as actions(like ‘fold’). This is all subjective in a functional setting!
Toggle quote (24 lines)> If we were looking for verbs that express the idea of creating an> environment or to place a thing inside of an environment we could use> one of these:>> to envelop (envelop what though? This seems to require two objects.)> to arrange (kinda misses the point)> to stage (in the theatric sense)> to frame (not in the criminal sense)> to contain (…the resulting process in a possibly leaky environment)> to join (…all these packages to form a new whole)> to group (…all these packages)>> (As a bonus: ‘to environ’ exists, but it suffers from the same problem> as ‘to envelop’.)>> Here are some nouns that might work:>> scene> frame> context> union>> All of them are shorter than “environment”! :)
More data points! :-)
Toggle snippet (24 lines)$ wn environment -synsn
Synonyms/Hypernyms (Ordered by Estimated Frequency) of noun environment
2 senses of environment
Sense 1environment => situation, state of affairs
Sense 2environment, environs, surroundings, surround => geographical area, geographic area, geographical region, geographic region$ wn environ -synsv
Synonyms/Hypernyms (Ordered by Estimated Frequency) of verb environ
1 sense of environ
Sense 1surround, environ, ring, skirt, border => touch, adjoin, meet, contact
Maybe “union”, “surround”, or… “profile”?
(I’d reserve “guix spawn” or “guix run” for the tool that runs commandsin a least-authority environment, as we’ve discussed in the past.)
Ludo’.
R
R
Ricardo Wurmus wrote on 31 Dec 2019 20:09
(name . Ludovic Courtès)(address . ludo@gnu.org)
877e2cnwgs.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (2 lines)> Maybe “union”, “surround”, or… “profile”?
“profile” is a tempting choice, but it’s treacherous because we might beblinded by the glow of the implementation of environments as volatileprofiles. On the other hand: if we could also move some of the featuresof the “package” sub-command under “profile” (e.g. those that relate tothe management of, well, profiles), that could be a winning move.
Tricky.
Toggle quote (3 lines)> (I’d reserve “guix spawn” or “guix run” for the tool that runs commands> in a least-authority environment, as we’ve discussed in the past.)
Same.
--Ricardo
Z
Z
zimoun wrote on 1 Jan 2020 20:23
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ2-n+xaMBazhdyp3fpjZ37vNGX+=7MespCQ+gyNOr_OEw@mail.gmail.com
Hi,
Happy New Year!(if you are using a gregorian calendar based on the January 1srt reform)

On Tue, 31 Dec 2019 at 20:09, Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (6 lines)> “profile” is a tempting choice, but it’s treacherous because we might be> blinded by the glow of the implementation of environments as volatile> profiles. On the other hand: if we could also move some of the features> of the “package” sub-command under “profile” (e.g. those that relate to> the management of, well, profiles), that could be a winning move.
If the new "guix profile" does more or less the same thing than thecurrent "guix environment", then I find the word "profile" confusingbecause the concept of "profile" is not exactly the same elsewhere.

However, if the current CLI is changed is a bit, for example splittingthe current "guix package", then why not.
I mean, let consider the new command 'profile' with subcommands: - guix profile new - guix profile listetc. i.e., managing the profiles as it has been recently described(sorry too lazy to correctly refer where, but e.g., this thread [1]).
*and* with the subcommand 'create' or 'temporary' or <naming-is-hard>,i.e., "guix profile create" doing more or less what the current "guixenvironment" is doing.
Wouaouw! It is far far away from the initial idea behind this thread. :-)

[1] https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00565.html



All the best,simon
A
A
Andy Wingo wrote on 2 Jan 2020 10:49
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87sgkyfary.fsf@igalia.com
On Fri 20 Dec 2019 22:08, Ricardo Wurmus <rekado@elephly.net> writes:
Toggle quote (10 lines)> zimoun <zimon.toutoune@gmail.com> writes:>>> - I propose the name "guix shell">> This is not a bad idea, especially considering that “guix environment”> was meant to get shebang support, so that you could use it as the> interpreter in a script that handles the environment configuration.>> It is also shorter.
I like this idea. It would also allow us to deprecate "guixenvironment" over a period of a year or so, and we can probably show anequivalent "guix shell" invocation in the deprecation message.
Andy
C
C
Christopher Lemmer Webber wrote on 3 Nov 2020 18:38
Re: bug#38529: Make --pure the default for `guix environment'?
(name . Ludovic Courtès)(address . ludo@gnu.org)
87y2jiwdba.fsf@dustycloud.org
Ludovic Courtès writes:
Toggle quote (20 lines)> Hello!>> "Thompson, David" <dthompson2@worcester.edu> skribis:>>> I have long thought that --ad-hoc should be implied, as that is the>> mode I use 99% of the time, but I disagree that --pure should be the>> default.>> I very much agree with that. I don’t think ‘--pure’ should be the> default, because there are valid use cases for that.>> As for ‘--ad-hoc’: making it the default is technically easy. The> difficulty is to come up with a nice transition/deprecation mechanism so> that we don’t break everyone’s script overnight.>> Ideas on how to achieve it are welcome!>> Thanks,> Ludo’.
It suddenly struck me today that there is an easy way to change thedefault behavior while supporting the legacy behavior.
How about we have a new command, "guix env", what is --ad-hoc bydefault? Then "guix environment" sticks around as legacy for supportingthe old interface. Therefore, "guix env" is doubly short and to thepoint. :)
Z
Z
zimoun wrote on 3 Nov 2020 19:35
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
87y2jie1aj.fsf@gmail.com
Hi,On Tue, 03 Nov 2020 at 12:38, Christopher Lemmer Webber <cwebber@dustycloud.org> wrote:
Toggle quote (2 lines)>> Ideas on how to achieve it are welcome!
[..]
Toggle quote (8 lines)> It suddenly struck me today that there is an easy way to change the> default behavior while supporting the legacy behavior.>> How about we have a new command, "guix env", what is --ad-hoc by> default? Then "guix environment" sticks around as legacy for supporting> the old interface. Therefore, "guix env" is doubly short and to the> point. :)
Rehashing all that, and because different POV on CLI pops up sometime,one move should be to have “aliases” [1]; I am sure the idea alreadycame long time before but I do not find the thread.

My understanding of the situation:
1- specific "guix foo" case: implement something like Alice proposed 2- add a mechanism to have aliases.
Replace ’foo’ by ’environment’, ’graph’, ’search’, ’show’, etc.

Let's expand explanations about the #2.
Now with “guix repl“, the user can extend Guix by their own scripts.Therefore, it could be nice:
a) to have a location by default (say ~/.config/guix/scripts) b) to run them with "guix foo" instead of "guix repl -- ~/.config/guix/scripts/foo.scm".
And then, we are all be happy. ;-)
It eases the tests of new experimental command-line tools, one can locallychange the behaviour of “guix environment --ad-hoc“, one can experimentwith new output formats for “guix search“ instead of ’recutils’, etc..
And using channel as “home-manager” or GWL [2] show, we could eveneasily exchange them. Somehow.
Well, the philosophy of custom extensions.

WDYT?
All the best,simon


1: http://issues.guix.gnu.org/issue/43477#112: related recent patch by Ricardo:https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00505.html
T
T
Taylan Kammer wrote on 4 Nov 2020 10:43
4419f87c-c3ee-84c8-0a35-366b5978b653@gmail.com
On 10.12.2019 18:16, Ludovic Courtès wrote:
Toggle quote (21 lines)> Hello!> > "Thompson, David" <dthompson2@worcester.edu> skribis:> >> I have long thought that --ad-hoc should be implied, as that is the>> mode I use 99% of the time, but I disagree that --pure should be the>> default.> > I very much agree with that. I don’t think ‘--pure’ should be the> default, because there are valid use cases for that.> > As for ‘--ad-hoc’: making it the default is technically easy. The> difficulty is to come up with a nice transition/deprecation mechanism so> that we don’t break everyone’s script overnight.> > Ideas on how to achieve it are welcome!> > Thanks,> Ludo’.>
I suppose the straightforward way of doing such a transition would be:
- In the next release, add --inputs-of and make the use of 'guix environment' with neither switch emit a warning saying you should use the new switch to explicitly enable it because the default will change.
- Later, change the default behavior and deprecate --ad-hoc as it becomes a no-op.
- (Optional) In some future release, remove --ad-hoc.

Taylan
C
C
Christopher Lemmer Webber wrote on 4 Nov 2020 17:05
(name . Taylan Kammer)(address . taylan.kammer@gmail.com)
87sg9p6rbm.fsf@dustycloud.org
Taylan Kammer writes:
Toggle quote (32 lines)> On 10.12.2019 18:16, Ludovic Courtès wrote:>> Hello!>> "Thompson, David" <dthompson2@worcester.edu> skribis:>> >>> I have long thought that --ad-hoc should be implied, as that is the>>> mode I use 99% of the time, but I disagree that --pure should be the>>> default.>> I very much agree with that. I don’t think ‘--pure’ should be the>> default, because there are valid use cases for that.>> As for ‘--ad-hoc’: making it the default is technically easy. The>> difficulty is to come up with a nice transition/deprecation mechanism so>> that we don’t break everyone’s script overnight.>> Ideas on how to achieve it are welcome!>> Thanks,>> Ludo’.>> >> I suppose the straightforward way of doing such a transition would be:>> - In the next release, add --inputs-of and make the use of 'guix> environment' with neither switch emit a warning saying you should> use the new switch to explicitly enable it because the default will> change.>> - Later, change the default behavior and deprecate --ad-hoc as it> becomes a no-op.>> - (Optional) In some future release, remove --ad-hoc.>>> Taylan
That sounds good to me.
And could we make "env" a shortcut for "environment" anyway? My fingersare tired. ;)
L
L
Ludovic Courtès wrote on 6 Nov 2020 10:03
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
87o8ka3li0.fsf@gnu.org
Hi!
Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
Toggle quote (8 lines)> It suddenly struck me today that there is an easy way to change the> default behavior while supporting the legacy behavior.>> How about we have a new command, "guix env", what is --ad-hoc by> default? Then "guix environment" sticks around as legacy for supporting> the old interface. Therefore, "guix env" is doubly short and to the> point. :)
Last time we discussed it we reached (I think!) a consensus that the newcommand would be called ‘guix shell’ and be ‘--ad-hoc’ by default.
I almost started working on it, and then got stuck wondering whether‘--inputs-of’ should be implemented as a package transformation or not.
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 38529@debbugs.gnu.org