* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 6:49 ` Konrad Hinsen
@ 2019-12-17 9:14 ` Gábor Boskovits
2019-12-17 9:14 ` Gábor Boskovits
` (4 subsequent siblings)
5 siblings, 0 replies; 87+ messages in thread
From: Gábor Boskovits @ 2019-12-17 9:14 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix-devel, 38529
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
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.
>
> 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.
>
>
> Cheers,
>
> Konrad.
>
Best regard,
g_bor
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3098 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 6:49 ` Konrad Hinsen
2019-12-17 9:14 ` Gábor Boskovits
@ 2019-12-17 9:14 ` Gábor Boskovits
2019-12-17 13:33 ` Kyle Meyer
` (3 more replies)
2019-12-17 17:07 ` zimoun
` (3 subsequent siblings)
5 siblings, 4 replies; 87+ messages in thread
From: Gábor Boskovits @ 2019-12-17 9:14 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix-devel, 38529
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
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.
>
> 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.
>
>
> Cheers,
>
> Konrad.
>
Best regard,
g_bor
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3098 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 9:14 ` Gábor Boskovits
@ 2019-12-17 13:33 ` Kyle Meyer
2019-12-17 13:33 ` Kyle Meyer
` (2 subsequent siblings)
3 siblings, 0 replies; 87+ messages in thread
From: Kyle Meyer @ 2019-12-17 13:33 UTC (permalink / raw)
To: Gábor Boskovits, Konrad Hinsen; +Cc: Guix-devel, 38529
Gábor Boskovits <boskovits@gmail.com> writes:
> Konrad Hinsen <konrad.hinsen@fastmail.net> 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"?
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 9:14 ` Gábor Boskovits
2019-12-17 13:33 ` Kyle Meyer
@ 2019-12-17 13:33 ` Kyle Meyer
2019-12-17 14:22 ` Brett Gilio
2019-12-17 14:22 ` Brett Gilio
2019-12-17 22:30 ` Bengt Richter
2019-12-17 22:30 ` Bengt Richter
3 siblings, 2 replies; 87+ messages in thread
From: Kyle Meyer @ 2019-12-17 13:33 UTC (permalink / raw)
To: Gábor Boskovits, Konrad Hinsen; +Cc: Guix-devel, 38529
Gábor Boskovits <boskovits@gmail.com> writes:
> Konrad Hinsen <konrad.hinsen@fastmail.net> 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"?
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 13:33 ` Kyle Meyer
@ 2019-12-17 14:22 ` Brett Gilio
2019-12-17 14:22 ` Brett Gilio
1 sibling, 0 replies; 87+ messages in thread
From: Brett Gilio @ 2019-12-17 14:22 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Guix-devel, 38529
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 596 bytes --]
Dec 17, 2019 7:34:17 AM Kyle Meyer :
> 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 13:33 ` Kyle Meyer
2019-12-17 14:22 ` Brett Gilio
@ 2019-12-17 14:22 ` Brett Gilio
1 sibling, 0 replies; 87+ messages in thread
From: Brett Gilio @ 2019-12-17 14:22 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Guix-devel, 38529
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 596 bytes --]
Dec 17, 2019 7:34:17 AM Kyle Meyer :
> 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 9:14 ` Gábor Boskovits
2019-12-17 13:33 ` Kyle Meyer
2019-12-17 13:33 ` Kyle Meyer
@ 2019-12-17 22:30 ` Bengt Richter
2019-12-17 23:21 ` Bengt Richter
2019-12-17 23:21 ` Bengt Richter
2019-12-17 22:30 ` Bengt Richter
3 siblings, 2 replies; 87+ messages in thread
From: Bengt Richter @ 2019-12-17 22:30 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, 38529
Hi Gábor, Konrad, et al
On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote:
> 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 least
first do the following at the command line:
which xxx
xxx --version
xxx --help
info xxx
man xxx
apropos xxx
#check for same prefix, case-insensitively,
# e.g. env might be tempting, as seen in this thread :)
--8<---------------cut here---------------start------------->8---
echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done
--8<---------------cut here---------------end--------------->8---
# -name "*xxx*" may also be a good idea, but the prefix is most important
# env* produces
/usr/bin/env
/usr/bin/envsubst
guix search xxx
guix package -A xxx
wikipedia search on xxx, e.g.
lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.php?search=xxx |less
You get the idea, I'm sure ;-)
> > How about a more drastic measure: deprecate "guix environment" and
> > introduce a new subcommand with the desired new behaviour?
> >
SGTM, with some caveats
Good, since calling different things by the same name is always going to be problematic.
Iffy, since calling the same thing by different names may reduce future naming options,
and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb.
> That is also the other option I was thinking about. Do you have any good
> idea in mind as how to call it? Of course the classic guix environment2
> comes to my mind, but it does not look very appealing to me.
>
Me neither :)
> >
> > Cheers,
> >
> > Konrad.
> >
> Best regard,
> g_bor
>
HTH in some way :)
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 22:30 ` Bengt Richter
@ 2019-12-17 23:21 ` Bengt Richter
2019-12-17 23:21 ` Bengt Richter
1 sibling, 0 replies; 87+ messages in thread
From: Bengt Richter @ 2019-12-17 23:21 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, 38529
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 regex
for the effect of
,a rest of line as regex
in the guile repl
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 22:30 ` Bengt Richter
2019-12-17 23:21 ` Bengt Richter
@ 2019-12-17 23:21 ` Bengt Richter
1 sibling, 0 replies; 87+ messages in thread
From: Bengt Richter @ 2019-12-17 23:21 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, 38529
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 regex
for the effect of
,a rest of line as regex
in the guile repl
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 9:14 ` Gábor Boskovits
` (2 preceding siblings ...)
2019-12-17 22:30 ` Bengt Richter
@ 2019-12-17 22:30 ` Bengt Richter
3 siblings, 0 replies; 87+ messages in thread
From: Bengt Richter @ 2019-12-17 22:30 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, 38529
Hi Gábor, Konrad, et al
On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote:
> 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 least
first do the following at the command line:
which xxx
xxx --version
xxx --help
info xxx
man xxx
apropos xxx
#check for same prefix, case-insensitively,
# e.g. env might be tempting, as seen in this thread :)
--8<---------------cut here---------------start------------->8---
echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done
--8<---------------cut here---------------end--------------->8---
# -name "*xxx*" may also be a good idea, but the prefix is most important
# env* produces
/usr/bin/env
/usr/bin/envsubst
guix search xxx
guix package -A xxx
wikipedia search on xxx, e.g.
lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.php?search=xxx |less
You get the idea, I'm sure ;-)
> > How about a more drastic measure: deprecate "guix environment" and
> > introduce a new subcommand with the desired new behaviour?
> >
SGTM, with some caveats
Good, since calling different things by the same name is always going to be problematic.
Iffy, since calling the same thing by different names may reduce future naming options,
and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb.
> That is also the other option I was thinking about. Do you have any good
> idea in mind as how to call it? Of course the classic guix environment2
> comes to my mind, but it does not look very appealing to me.
>
Me neither :)
> >
> > Cheers,
> >
> > Konrad.
> >
> Best regard,
> g_bor
>
HTH in some way :)
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 6:49 ` Konrad Hinsen
2019-12-17 9:14 ` Gábor Boskovits
2019-12-17 9:14 ` Gábor Boskovits
@ 2019-12-17 17:07 ` zimoun
2019-12-17 17:07 ` zimoun
` (2 subsequent siblings)
5 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-17 17:07 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> 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 is
documented.
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>".
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.
> 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. ;-)
> 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 loose
the good name "guix environment"... and we know that naming is hard.
;-)
What about "guix shell"?
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 6:49 ` Konrad Hinsen
` (2 preceding siblings ...)
2019-12-17 17:07 ` zimoun
@ 2019-12-17 17:07 ` zimoun
2019-12-18 9:43 ` Konrad Hinsen
2019-12-18 9:43 ` Konrad Hinsen
2019-12-19 16:31 ` bug#38529: Deprecating ‘guix environment’? Ludovic Courtès
2019-12-19 16:31 ` Ludovic Courtès
5 siblings, 2 replies; 87+ messages in thread
From: zimoun @ 2019-12-17 17:07 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> 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 is
documented.
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>".
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.
> 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. ;-)
> 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 loose
the good name "guix environment"... and we know that naming is hard.
;-)
What about "guix shell"?
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 17:07 ` zimoun
@ 2019-12-18 9:43 ` Konrad Hinsen
2019-12-18 13:09 ` zimoun
` (4 more replies)
2019-12-18 9:43 ` Konrad Hinsen
1 sibling, 5 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-18 9:43 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, 38529
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?
> 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
>> 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!
> 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.
Cheers,
Konrad
^ permalink raw reply [flat|nested] 87+ messages in thread* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 9:43 ` Konrad Hinsen
@ 2019-12-18 13:09 ` zimoun
2019-12-18 13:09 ` zimoun
` (3 subsequent siblings)
4 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-18 13:09 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> 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 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.
> > 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-hoc
option 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 for
time-travelling, I mean it is easy to correct adding the --inputs-of
option or set the GUIX_ENVIRONMENT_DEPRECATED variable.
> > 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
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 9:43 ` Konrad Hinsen
2019-12-18 13:09 ` zimoun
@ 2019-12-18 13:09 ` zimoun
2019-12-20 11:24 ` Konrad Hinsen
2019-12-20 11:24 ` Konrad Hinsen
2019-12-18 20:55 ` Arne Babenhauserheide
` (2 subsequent siblings)
4 siblings, 2 replies; 87+ messages in thread
From: zimoun @ 2019-12-18 13:09 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
>
> 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 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.
> > 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-hoc
option 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 for
time-travelling, I mean it is easy to correct adding the --inputs-of
option or set the GUIX_ENVIRONMENT_DEPRECATED variable.
> > 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
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 13:09 ` zimoun
@ 2019-12-20 11:24 ` Konrad Hinsen
2019-12-20 12:03 ` zimoun
2019-12-20 11:24 ` Konrad Hinsen
1 sibling, 1 reply; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-20 11:24 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, 38529
Hi Simon,
> 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, no
matter 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 very
discouraging to see examples from tutorials fail or do something weird.
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.
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.
Cheers,
Konrad.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 11:24 ` Konrad Hinsen
@ 2019-12-20 12:03 ` zimoun
2019-12-20 21:08 ` Ricardo Wurmus
0 siblings, 1 reply; 87+ messages in thread
From: zimoun @ 2019-12-20 12:03 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Fri, 20 Dec 2019 at 12:24, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
> 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.
> 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.
> 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 the
cost of the change is low.
However, we cannot know this cost, only probe and estimate: using my
probings, 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 and
I feel a blocking situation so I will move forward to another topic.
:-)
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 12:03 ` zimoun
@ 2019-12-20 21:08 ` Ricardo Wurmus
2019-12-23 9:28 ` Danny Milosavljevic
` (2 more replies)
0 siblings, 3 replies; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-20 21:08 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, 38529
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.
--
Ricardo
^ permalink raw reply [flat|nested] 87+ messages in thread* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:08 ` Ricardo Wurmus
@ 2019-12-23 9:28 ` Danny Milosavljevic
2019-12-23 9:28 ` Danny Milosavljevic
2020-01-02 9:49 ` Andy Wingo
2 siblings, 0 replies; 87+ messages in thread
From: Danny Milosavljevic @ 2019-12-23 9:28 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Guix Devel, 38529
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi Ricardo,
On Fri, 20 Dec 2019 22:08:48 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:
> 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 all
be subsumed into the first argument.
#!foo bar baz
foo gets: $1="bar baz", $#=2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:08 ` Ricardo Wurmus
2019-12-23 9:28 ` Danny Milosavljevic
@ 2019-12-23 9:28 ` Danny Milosavljevic
2020-01-02 9:49 ` Andy Wingo
2 siblings, 0 replies; 87+ messages in thread
From: Danny Milosavljevic @ 2019-12-23 9:28 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Guix Devel, 38529
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi Ricardo,
On Fri, 20 Dec 2019 22:08:48 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:
> 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 all
be subsumed into the first argument.
#!foo bar baz
foo gets: $1="bar baz", $#=2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:08 ` Ricardo Wurmus
2019-12-23 9:28 ` Danny Milosavljevic
2019-12-23 9:28 ` Danny Milosavljevic
@ 2020-01-02 9:49 ` Andy Wingo
2 siblings, 0 replies; 87+ messages in thread
From: Andy Wingo @ 2020-01-02 9:49 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Guix Devel, 38529
On Fri 20 Dec 2019 22:08, Ricardo Wurmus <rekado@elephly.net> writes:
> 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 "guix
environment" over a period of a year or so, and we can probably show an
equivalent "guix shell" invocation in the deprecation message.
Andy
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 13:09 ` zimoun
2019-12-20 11:24 ` Konrad Hinsen
@ 2019-12-20 11:24 ` Konrad Hinsen
1 sibling, 0 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-20 11:24 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, 38529
Hi Simon,
> 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, no
matter 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 very
discouraging to see examples from tutorials fail or do something weird.
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.
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.
Cheers,
Konrad.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 9:43 ` Konrad Hinsen
2019-12-18 13:09 ` zimoun
2019-12-18 13:09 ` zimoun
@ 2019-12-18 20:55 ` Arne Babenhauserheide
2019-12-19 11:30 ` zimoun
2019-12-20 21:12 ` Ricardo Wurmus
2019-12-20 21:12 ` Ricardo Wurmus
4 siblings, 1 reply; 87+ messages in thread
From: Arne Babenhauserheide @ 2019-12-18 20:55 UTC (permalink / raw)
To: bug-guix; +Cc: Guix Devel, 38529
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
> 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 sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 20:55 ` Arne Babenhauserheide
@ 2019-12-19 11:30 ` zimoun
2019-12-19 21:39 ` Arne Babenhauserheide
0 siblings, 1 reply; 87+ messages in thread
From: zimoun @ 2019-12-19 11:30 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: Guix Devel, bug-guix, 38529
Hi Arne,
Thank you for the pointers.
On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide <arne_bab@web.de> wrote:
> 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 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.
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 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 ;-).
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.
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. ;-)
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).
Last, "volatile" vs "stable" is mitigated by "The future of 'guix
environment'" [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 be
broken, too much time to fix the break, etc. and this proposal would
lead to disaster for the end-user. But it is my opinion based on my
restricted personal experience.
> 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-19 11:30 ` zimoun
@ 2019-12-19 21:39 ` Arne Babenhauserheide
2019-12-19 22:40 ` zimoun
0 siblings, 1 reply; 87+ messages in thread
From: Arne Babenhauserheide @ 2019-12-19 21:39 UTC (permalink / raw)
To: zimoun; +Cc: guix-devel, 38529
[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]
Hi zimoun,
zimoun <zimon.toutoune@gmail.com> writes:
>> 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, 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.
> 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 there
is existing third-party documentation about using `guix environment`.
And can you name the people using `guix environment` by searching
backwards in their bash history?
> 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.
> 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.
You don’t need to be able to go back in time, but the path forward must
be without breakage.
> 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`.
> 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.
>> 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.
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.
> 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 common
commands when called without argument (as `guix`) — excluding
guix environment.
That would not avoid the slow version of traumatic changes, but if
guix environment would keep working and both guix env/guix shell/… and
guix environment used the same backend (just with different options),
then they would be minimized, because guix environment would not become
a second-class citizen.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-19 21:39 ` Arne Babenhauserheide
@ 2019-12-19 22:40 ` zimoun
2019-12-20 1:37 ` Arne Babenhauserheide
0 siblings, 1 reply; 87+ messages in thread
From: zimoun @ 2019-12-19 22:40 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: guix-devel, 38529
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:
> 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.
> > 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.
> 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!)
> > 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?
> > 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?
[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.
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.
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.
> > 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?
> >> 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!
> 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 not
tell that I am traumatized.
Regards,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-19 22:40 ` zimoun
@ 2019-12-20 1:37 ` Arne Babenhauserheide
2019-12-20 11:40 ` zimoun
0 siblings, 1 reply; 87+ messages in thread
From: Arne Babenhauserheide @ 2019-12-20 1:37 UTC (permalink / raw)
To: zimoun; +Cc: guix-devel, 38529
[-- Attachment #1: Type: text/plain, Size: 10413 bytes --]
zimoun <zimon.toutoune@gmail.com> writes:
> First, have you read the proposal?
Yes.
> 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.
>> 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 not
mean that there is no problem with breaking the way forward. Using only
old versions is often not an option. Just imagine running audio software
from 5 years ago on a system that only provides pulseaudio (or whatever
will come after it). Imagine using an old KDE DCOP-based automation
workflow on a dbus-system. You need to update the libraries you use to
get it working at all.
>> > 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/
>> 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 spawn
instantly. It takes many minutes until it is ready. If I then have to go
back, find the warning (it’s likely that I’d miss it, because these are
things that work, and suddenly they break, which I’m likely to only
figure out when the followup steps don’t work) and run it again, that
often 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 painful
ones. Maybe avoid calling it "DEPRECATED" and instead give it a more
descriptive name that does not imply that it will go away.
Mercurial uses HGPLAIN=1 to say "I want the version which will never
change established API". Best practice is to always use that in scripts
— and that is a stable best practice. But this is also slow to receive
new features.
If the old way to use guix environment is intended to actually be legacy
only, then it could be a way forward to also provide
GUIX_ENVIRONMENT_STABLE=1 which gives an API that is guaranteed to never
change the meaning of options again *after the change that’s been
started to brew in 2017*.
That would be a purely append-only API then, and while it would break
once, it would prevent such changes for the future.
For PR it might be possible to state that with this change, guix
environment as a tool reaches version 0.99 (to be updated to 1.0 after
sufficient testing).
>> > 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 still
have in history.
>> > 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 email
discussion. 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 say
whether the churn due to the breaking change or the annoyance due to
suboptimal default behavior will be worse.
> [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-date
libraries. Just imagine using a rust-tool but being stuck in a 12 months
old environment that you cannot update without breakage.
> 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: There
are tools which almost never break. And there are tools that almost
always break.
If you use a tool out of the latter group, you’re in for a world of
pain. It’s why it took years and years for somewhat stable git-wrappers
to appear: The early wrappers that made git easier to use always broke
when git changed operation. Guix environment might actually help you
delay the update until you have time to deal with the breakage.
> 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 for
doing so isn’t volatile itself.
>> > 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 the
future above :-)
>> >> 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 reaction
people feel when something into which they invested time suddenly stops
working as expected.
>> 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 into
the future, then you found part of the holy grail of software
development: You managed to find one fragment that’s so good that it
never needs to change again and everything new you do fits to it.
Typically reality isn’t quite as beautiful and change can break your
model. They say about Lisp that it’s a snowball: You can keep adding
stuff 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 only
try to limit the pain for users and stay close to something which feels
right.
Volatile projects do not work to limit the pain.
Stale projects do not try to stay close to ways that feel right in a
changing reality.
A good project needs to get as close as possible to a consensus (I’m not
saying compromise here, because that’s not what I mean — the goal is
something which unites both) between not being volatile and not becoming
stale.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 1:37 ` Arne Babenhauserheide
@ 2019-12-20 11:40 ` zimoun
2019-12-20 21:31 ` Ricardo Wurmus
2019-12-20 23:02 ` Arne Babenhauserheide
0 siblings, 2 replies; 87+ messages in thread
From: zimoun @ 2019-12-20 11:40 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: Guix Devel, bug-guix, 38529
Hi Arne,
On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide <arne_bab@web.de> wrote:
> > 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 the
current behaviour and proposes a change (see "The future of 'guix
environment'").
- 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 I
propose a name for this "new" command: "guix shell".
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.
Then, your following answer is more about your feelings than concrete
examples. It is hard to know in advance how many scripts or use-cases
would 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 or
at better a flame war about "backward compatibility", I prefer going
to spend my time elsewhere (still about Guix :-)).
I mean, I proposed, I said my opinion and I called to collect more
opinions. I feel I did my best on this front and other fronts deserve
proposals and fixes.
Kind regards,
simon
ps:
Note that I did a proposal which could be a path to reduce the burden
of "guix pull" breakage: adding tags. Feel free to comment.
https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 11:40 ` zimoun
@ 2019-12-20 21:31 ` Ricardo Wurmus
2019-12-21 8:40 ` Gábor Boskovits
2019-12-21 16:51 ` Ludovic Courtès
2019-12-20 23:02 ` Arne Babenhauserheide
1 sibling, 2 replies; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-20 21:31 UTC (permalink / raw)
To: zimoun; +Cc: GNU Guix maintainers, 38529
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”.
I wonder what the other maintainers think about this.
--
Ricardo
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:31 ` Ricardo Wurmus
@ 2019-12-21 8:40 ` Gábor Boskovits
2019-12-21 16:51 ` Ludovic Courtès
1 sibling, 0 replies; 87+ messages in thread
From: Gábor Boskovits @ 2019-12-21 8:40 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2019. dec. 20., Pén
22:32):
>
> 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 original
ideas presented here, and what you say about having a stable api can be
easily synchronized by naming the environment variable to something like
GUIX_CLI_API_VERSION. I would propose it to be of the form 1.0.1.0, so that
the first three numbers could be the current guix version. Havin it this
way would allow inter releas updates bumping the last number, and the
ability to easily set a new default when the major version is bumped, which
implies a breaking change anyways. From there on the question would be what
should be the default? I would say, that is should be
<current-mayor>.0.0.0. Does that make sense? Maybe we could come up with
something simpler, like dropping the second and third number.
>
> I wonder what the other maintainers think about this.
>
> --
> Ricardo
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3521 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:31 ` Ricardo Wurmus
2019-12-21 8:40 ` Gábor Boskovits
@ 2019-12-21 16:51 ` Ludovic Courtès
2019-12-30 9:44 ` EuAndreh via Bug reports for GNU Guix
1 sibling, 1 reply; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-21 16:51 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
Hi!
Ricardo Wurmus <rekado@elephly.net> skribis:
> 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.
> 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 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.
> 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, I
would distinguish core APIs, peripheral APIs (e.g., the importers), (gnu
system …) 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 between
the core facilities (the core Scheme APIs?) and the porcelain?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-21 16:51 ` Ludovic Courtès
@ 2019-12-30 9:44 ` EuAndreh via Bug reports for GNU Guix
2019-12-30 10:34 ` Ludovic Courtès
0 siblings, 1 reply; 87+ messages in thread
From: EuAndreh via Bug reports for GNU Guix @ 2019-12-30 9:44 UTC (permalink / raw)
To: Ludovic Courtès, Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
Hello :)
Jumping in the discussion xD
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?
Suppose the path of adding new subcommand is chosen, and it is "guix
shell". 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 become
deprecated, but no current usage of it would stop working, and no public
references to it in the internet would become misleading. "guix
environment" could say that is has been deprecated, and point to "guix
shell", but keep working the same way.
If desired, "guix environment" could be removed after X time of
deprecation has passed, but that would be optional.
What are the downsides? Am I missing something?
Thanks,
euandreh.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 9:44 ` EuAndreh via Bug reports for GNU Guix
@ 2019-12-30 10:34 ` Ludovic Courtès
2019-12-30 12:03 ` zimoun
0 siblings, 1 reply; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-30 10:34 UTC (permalink / raw)
To: EuAndreh; +Cc: GNU Guix maintainers, 38529
Hi,
EuAndreh <eu@euandre.org> skribis:
> 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 is
about. No good idea, though.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 10:34 ` Ludovic Courtès
@ 2019-12-30 12:03 ` zimoun
2019-12-30 15:06 ` Ludovic Courtès
0 siblings, 1 reply; 87+ messages in thread
From: zimoun @ 2019-12-30 12:03 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: EuAndreh, GNU Guix maintainers, 38529
Hi Ludo,
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?
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 backward
compatibility argument because all the current documentation/scripts
using it will not work anymore. Other said, if the
documentation/scripts cannot be updated as it was said -- in favor for
strong backward compatibility -- then the user will be surprised that
what worked does not anymore because the command does not exist
anymore.
Therefore, if Guix goes the backward compatibility route, then the
"guix environment" should be frozen until the version 2.0 and so only
removed when the 2.0 will be released. Or I misunderstand the
arguments in favor of the backward compatibility.
As Arne described the process (bottom of [1]), "guix environment" will
become a kind-of alias of "guix shell/<name-it>". Right?
> 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 if
we argument why we collectively find that name or this name is bad or
good, one of us will find the good name. Currently, "guix shell" seems
the better option.
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 12:03 ` zimoun
@ 2019-12-30 15:06 ` Ludovic Courtès
2019-12-30 17:55 ` zimoun
0 siblings, 1 reply; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-30 15:06 UTC (permalink / raw)
To: zimoun; +Cc: EuAndreh, GNU Guix maintainers, 38529
Hello!
zimoun <zimon.toutoune@gmail.com> skribis:
> 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 not
stating anything as to what solution we should implement. :-)
> 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.
> As Arne described the process (bottom of [1]), "guix environment" will
> become a kind-of alias of "guix shell/<name-it>". Right?
Yes.
>> 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!
> 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.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 15:06 ` Ludovic Courtès
@ 2019-12-30 17:55 ` zimoun
2019-12-30 21:10 ` Ricardo Wurmus
0 siblings, 1 reply; 87+ messages in thread
From: zimoun @ 2019-12-30 17:55 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: GNU Guix maintainers, 38529
Hey!
On Mon, 30 Dec 2019 at 16:06, Ludovic Courtès <ludo@gnu.org> wrote:
> 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. ;-)
> > 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 17:55 ` zimoun
@ 2019-12-30 21:10 ` Ricardo Wurmus
2019-12-30 21:32 ` zimoun
2019-12-31 18:09 ` Ludovic Courtès
0 siblings, 2 replies; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-30 21:10 UTC (permalink / raw)
To: zimoun; +Cc: GNU Guix maintainers, 38529
zimoun <zimon.toutoune@gmail.com> writes:
>> > 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 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’.
Thinking about words some more I started to wonder: do we want verbs or
nouns? 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 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”! :)
What do you think?
--
Ricardo
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 21:10 ` Ricardo Wurmus
@ 2019-12-30 21:32 ` zimoun
2019-12-31 18:09 ` Ludovic Courtès
1 sibling, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-30 21:32 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
Hi Ricardo,
Thank you for your input.
On Mon, 30 Dec 2019 at 22:10, Ricardo Wurmus <rekado@elephly.net> wrote:
> 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:
> 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-30 21:10 ` Ricardo Wurmus
2019-12-30 21:32 ` zimoun
@ 2019-12-31 18:09 ` Ludovic Courtès
2019-12-31 19:09 ` Ricardo Wurmus
1 sibling, 1 reply; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-31 18:09 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
Hi!
Ricardo Wurmus <rekado@elephly.net> skribis:
> zimoun <zimon.toutoune@gmail.com> writes:
[...]
>> 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.
> 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 nice
that 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!
> 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! :-)
--8<---------------cut here---------------start------------->8---
$ wn environment -synsn
Synonyms/Hypernyms (Ordered by Estimated Frequency) of noun environment
2 senses of environment
Sense 1
environment
=> situation, state of affairs
Sense 2
environment, 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 1
surround, environ, ring, skirt, border
=> touch, adjoin, meet, contact
--8<---------------cut here---------------end--------------->8---
Maybe “union”, “surround”, or… “profile”?
(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.)
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-31 18:09 ` Ludovic Courtès
@ 2019-12-31 19:09 ` Ricardo Wurmus
2020-01-01 19:23 ` zimoun
0 siblings, 1 reply; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-31 19:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: GNU Guix maintainers, 38529
Ludovic Courtès <ludo@gnu.org> writes:
> Maybe “union”, “surround”, or… “profile”?
“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.
Tricky.
> (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
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-31 19:09 ` Ricardo Wurmus
@ 2020-01-01 19:23 ` zimoun
0 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2020-01-01 19:23 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: GNU Guix maintainers, 38529
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:
> “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 the
current "guix environment", then I find the word "profile" confusing
because the concept of "profile" is not exactly the same elsewhere.
However, if the current CLI is changed is a bit, for example splitting
the current "guix package", then why not.
I mean, let consider the new command 'profile' with subcommands:
- guix profile new
- guix profile list
etc. 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 "guix
environment" 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
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 11:40 ` zimoun
2019-12-20 21:31 ` Ricardo Wurmus
@ 2019-12-20 23:02 ` Arne Babenhauserheide
2019-12-21 0:04 ` zimoun
1 sibling, 1 reply; 87+ messages in thread
From: Arne Babenhauserheide @ 2019-12-20 23:02 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, bug-guix, 38529
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Hi zimoun,
zimoun <zimon.toutoune@gmail.com> writes:
> 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.
The volatile software article describes that software differs in how
much work it is to keep using it. The traumatic change article discusses
one aspect why people stop using projects.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 23:02 ` Arne Babenhauserheide
@ 2019-12-21 0:04 ` zimoun
0 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-21 0:04 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: Guix Devel, bug-guix, 38529
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, I
am 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 since
the very beginning of this discussion to collect opinions from the
other fellow hackers.
Expressing the feelings is better than bitterness. Therefore I express
mines. :-)
I could send that privately because I am not sure it deserves to be
public. But let wash the laundry in family (translation from French
expression ;-))
On Sat, 21 Dec 2019 at 00:02, Arne Babenhauserheide <arne_bab@web.de> wrote:
> > 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 Collins
Dictionnary: "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; bah
I am a big boy, that's ok.
Again, to be on the same wavelength, the blog says: "The result has
been hugely divisive and intimately familiar to anyone who works with
Python, creating massive rifts in the community and wasting millions
of hours of engineer time addressing. This kind of “strong” trauma is
fairly easy to spot in advance."
Well, I understand when speaking about Python. Are we comparing the
number of Guix users with the number of Python users? Are we comparing
the number of changes between Python 2 and 3 with the change of the
default "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 are
more subtle than with strong traumatic changes." and then "The
opportunity to solve this problem by rewriting with asyncio in mind,
however, also presents me a chance to rewrite in anything else, and
reevaluate 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 so
are we really talking about this second "trauma"? On the other hand,
because "guix environment" will be better and users probably need to
rethink how they use Guix, then they will fully drop Guix.
Maybe "feelings" (quoting, in citation quoted too) is not the right
word. My point is all is vague. Example: I have the feeling that my
students(*) do not like Scheme; do I need to switch next year to
another language? Then do I make my decision based on my feelings?
based on the feelings of the students who are retaking the year (could
be shocked)? Me, I will make my decision based on: how many students
failed? what do they understand? what could be better for all the
students? what could be a better language? what is the ratio between
the new student vs the retaking ones? how many length the Scheme
textbook is? etc. Well, analogy is just analogy.
Well, that's it. I expressed what it appears to me a trail going
nowhere. Let move forward and put energy in "backward compatibility"
discussion: does Guix want? what does it imply? which level? etc. for
example, 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 1
year fighting to switch from C. Whatever! :-)
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 9:43 ` Konrad Hinsen
` (2 preceding siblings ...)
2019-12-18 20:55 ` Arne Babenhauserheide
@ 2019-12-20 21:12 ` Ricardo Wurmus
2019-12-20 21:12 ` Ricardo Wurmus
4 siblings, 0 replies; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-20 21:12 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
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?
I wonder if we should simply bump the version number to indicate that
this is a breaking change?
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
there’s a real maintenance cost (it seems small in this case), but
configuration files can be used for changing new defaults.
--
Ricardo
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-18 9:43 ` Konrad Hinsen
` (3 preceding siblings ...)
2019-12-20 21:12 ` Ricardo Wurmus
@ 2019-12-20 21:12 ` Ricardo Wurmus
2019-12-21 15:18 ` Konrad Hinsen
2019-12-21 15:18 ` Konrad Hinsen
4 siblings, 2 replies; 87+ messages in thread
From: Ricardo Wurmus @ 2019-12-20 21:12 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
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?
I wonder if we should simply bump the version number to indicate that
this is a breaking change?
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
there’s a real maintenance cost (it seems small in this case), but
configuration files can be used for changing new defaults.
--
Ricardo
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:12 ` Ricardo Wurmus
@ 2019-12-21 15:18 ` Konrad Hinsen
2019-12-21 15:18 ` Konrad Hinsen
1 sibling, 0 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-21 15:18 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Guix Devel, 38529
Hi Ricardo,
> 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?
> 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 similar
situations 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.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-20 21:12 ` Ricardo Wurmus
2019-12-21 15:18 ` Konrad Hinsen
@ 2019-12-21 15:18 ` Konrad Hinsen
1 sibling, 0 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-21 15:18 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: Guix Devel, 38529
Hi Ricardo,
> 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?
> 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 similar
situations 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.
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
2019-12-17 17:07 ` zimoun
2019-12-18 9:43 ` Konrad Hinsen
@ 2019-12-18 9:43 ` Konrad Hinsen
1 sibling, 0 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-18 9:43 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, 38529
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?
> 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
>> 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!
> 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.
Cheers,
Konrad
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Deprecating ‘guix environment’?
2019-12-17 6:49 ` Konrad Hinsen
` (3 preceding siblings ...)
2019-12-17 17:07 ` zimoun
@ 2019-12-19 16:31 ` Ludovic Courtès
2019-12-19 16:31 ` Ludovic Courtès
5 siblings, 0 replies; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-19 16:31 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: guix-devel, 38529
Hi Konrad,
Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
> 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.
> 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 altogether
while also allowing for further changes.
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?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread* Deprecating ‘guix environment’?
2019-12-17 6:49 ` Konrad Hinsen
` (4 preceding siblings ...)
2019-12-19 16:31 ` bug#38529: Deprecating ‘guix environment’? Ludovic Courtès
@ 2019-12-19 16:31 ` Ludovic Courtès
2019-12-19 22:48 ` bug#38529: " zimoun
` (3 more replies)
5 siblings, 4 replies; 87+ messages in thread
From: Ludovic Courtès @ 2019-12-19 16:31 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: guix-devel, 38529
Hi Konrad,
Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
> 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.
> 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 altogether
while also allowing for further changes.
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?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 87+ messages in thread* bug#38529: Deprecating ‘guix environment’?
2019-12-19 16:31 ` Ludovic Courtès
@ 2019-12-19 22:48 ` zimoun
2019-12-19 22:48 ` zimoun
` (2 subsequent siblings)
3 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-19 22:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel, 38529
On Thu, 19 Dec 2019 at 17:31, Ludovic Courtès <ludo@gnu.org> wrote:
> The hard question then becomes: what do we call it? I vote against
> abbreviations. :-)
"guix shell"?
Cheers,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: Deprecating ‘guix environment’?
2019-12-19 16:31 ` Ludovic Courtès
2019-12-19 22:48 ` bug#38529: " zimoun
@ 2019-12-19 22:48 ` zimoun
2019-12-20 11:17 ` Konrad Hinsen
2019-12-20 11:17 ` Konrad Hinsen
3 siblings, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-19 22:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel, 38529
On Thu, 19 Dec 2019 at 17:31, Ludovic Courtès <ludo@gnu.org> wrote:
> The hard question then becomes: what do we call it? I vote against
> abbreviations. :-)
"guix shell"?
Cheers,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Deprecating ‘guix environment’?
2019-12-19 16:31 ` Ludovic Courtès
2019-12-19 22:48 ` bug#38529: " zimoun
2019-12-19 22:48 ` zimoun
@ 2019-12-20 11:17 ` Konrad Hinsen
2019-12-20 13:21 ` zimoun
2019-12-20 13:21 ` bug#38529: " zimoun
2019-12-20 11:17 ` Konrad Hinsen
3 siblings, 2 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-20 11:17 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, 38529
Hi Ludo,
> 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 a
topic 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 policy
early on, state it clearly in their documentation, and stick to it. That
prevents misunderstandings, bad surprises, and heated debates.
As for what that policy should be for Guix, that's a more difficult
story. For projects with versioned releases, I like the principles
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.
> 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.
How about a unified command for constructing environments and profiles
declaratively? In other words, combine "guix environment" and the
declarative parts of "guix package". We could probably get rid of
the somewhat obscure "guix environment -r" in the process.
Cheers,
Konrad.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Deprecating ‘guix environment’?
2019-12-20 11:17 ` Konrad Hinsen
@ 2019-12-20 13:21 ` zimoun
2019-12-20 13:21 ` bug#38529: " zimoun
1 sibling, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-20 13:21 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
> 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 been
raises in the "heated" debate with Arne. :-)
> 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 in
the 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 or
specific ones?
> 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 for
packages.
Re-hashing this "guix tag" or "guix pull --tag" proposal, one idea
could be to introduce tags, say v1.1, v1.2, v1.3 etc bumping the
version 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 are
stable (no "guix pull" break, etc.)
[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
> > 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 'guix
environment'".
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Deprecating ‘guix environment’?
2019-12-20 11:17 ` Konrad Hinsen
2019-12-20 13:21 ` zimoun
@ 2019-12-20 13:21 ` zimoun
1 sibling, 0 replies; 87+ messages in thread
From: zimoun @ 2019-12-20 13:21 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: Guix Devel, 38529
Hi Konrad,
On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
> 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 been
raises in the "heated" debate with Arne. :-)
> 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 in
the 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 or
specific ones?
> 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 for
packages.
Re-hashing this "guix tag" or "guix pull --tag" proposal, one idea
could be to introduce tags, say v1.1, v1.2, v1.3 etc bumping the
version 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 are
stable (no "guix pull" break, etc.)
[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
> > 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 'guix
environment'".
All the best,
simon
^ permalink raw reply [flat|nested] 87+ messages in thread
* bug#38529: Deprecating ‘guix environment’?
2019-12-19 16:31 ` Ludovic Courtès
` (2 preceding siblings ...)
2019-12-20 11:17 ` Konrad Hinsen
@ 2019-12-20 11:17 ` Konrad Hinsen
3 siblings, 0 replies; 87+ messages in thread
From: Konrad Hinsen @ 2019-12-20 11:17 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel, 38529
Hi Ludo,
> 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 a
topic 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 policy
early on, state it clearly in their documentation, and stick to it. That
prevents misunderstandings, bad surprises, and heated debates.
As for what that policy should be for Guix, that's a more difficult
story. For projects with versioned releases, I like the principles
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.
> 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.
How about a unified command for constructing environments and profiles
declaratively? In other words, combine "guix environment" and the
declarative parts of "guix package". We could probably get rid of
the somewhat obscure "guix environment -r" in the process.
Cheers,
Konrad.
^ permalink raw reply [flat|nested] 87+ messages in thread