On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes:
> zimoun 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
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 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
>
Ludovic Courtès 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
Hi!
Ricardo Wurmus skribis:
> zimoun 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
Hi Ricardo,
Thank you for your input.
On Mon, 30 Dec 2019 at 22:10, Ricardo Wurmus wrote:
> zimoun 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
zimoun 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
Hey!
On Mon, 30 Dec 2019 at 16:06, Ludovic Courtès wrote:
> zimoun skribis:
> > On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès 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
Hello!
zimoun skribis:
> On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès 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
Hi Ludo,
On Mon, 30 Dec 2019 at 11:35, Ludovic Courtès 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
Hi,
EuAndreh skribis:
> Ludovic Courtès 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
Hello :)
Jumping in the discussion xD
Ludovic Courtès 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
Hi Ricardo,
On Fri, 20 Dec 2019 22:08:48 +0100
Ricardo Wurmus wrote:
> zimoun 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
Hi!
Ricardo Wurmus 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
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
Ricardo Wurmus ezt írta (időpont: 2019. dec. 20., Pén
22:32):
>
> zimoun 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.
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
zimoun 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
Konrad Hinsen 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 in ".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible
zimoun 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
Hi Konrad,
On Fri, 20 Dec 2019 at 12:24, Konrad Hinsen 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
Hi Arne,
On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide 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
>
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
zimoun 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
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 wrote:
> zimoun writes:
> > Guix is not a volatile software and will never be. Because it is
> > rooted in
Hi zimoun,
zimoun 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 --manifest=", "guix
>
Hi Arne,
Thank you for the pointers.
On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide wrote:
> Konrad Hinsen 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
Konrad Hinsen 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 in ".
>
> Concrete example: I am writing a tutorial about using Guix for
>
Hi Konrad,
On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen 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 in ".
>
> Concrete example: I
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 in ".
Concrete example: I am writing a tutorial about using Guix for
reproducible research. It shows
Forgot to add:
┌──┐
│ guile -c '(use-modules (ice-9 session))(apropos "env") │
├──┤
│ (guile): getenv #
Hi Gábor, Konrad, et al
On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote:
> Hello Konrad,
>
> Konrad Hinsen ezt írta (időpont: 2019. dec.
> 17., Ke 7:52):
>
> > On 16/12/2019 23:09, Ludovic Courtès wrote:
> > > So in a more algorithmic manner:
> > >> 1. if ad-hoc and inputs-of is present
Hi Konrad,
On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen 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
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?
> >
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
Hello Konrad,
Konrad Hinsen ezt írta (időpont: 2019. dec.
17., Ke 7:52):
> On 16/12/2019 23:09, Ludovic Courtès wrote:
> > So in a more algorithmic manner:
> >> 1. if ad-hoc and inputs-of is present at the same invocation: fail
> >> hard. (With an error like incompatible options present)
> >>
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
Hello,
Gábor Boskovits skribis:
> 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
Hi Gábor,
Sorry to be slow. :-)
On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits 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
Hello Zimoun,
zimoun ezt írta (időpont: 2019. dec. 13., P, 17:32):
>
> Hi Gábor,
>
> Sorry to be slow. :-)
I probably just did not express myself clearly enough.
>
> On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote:
>
>
> > So in a more algorithmic manner:
> > 1. if ad-hoc and inputs-of is
Hello,
Let me try again :)
zimoun ezt írta (időpont: 2019. dec. 13., P, 13:02):
>
> Hi Gábor,
>
>
> On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote:
>
> > zimoun ezt írta (időpont: 2019. dec. 12., Csü
> > 17:47):
>
> >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
>
Hi Gábor,
On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote:
> zimoun ezt írta (időpont: 2019. dec. 12., Csü
> 17:47):
>> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
>> with a different effect? Or why do we want to conserve this option
>> name?
>> It appears to me
Hello,
zimoun ezt írta (időpont: 2019. dec. 12., Csü
17:47):
> Hi Gábor,
>
> Thank you for summarizing the discussion on IRC that I missed.
>
> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
> with a different effect? Or why do we want to conserve this option
> name?
> It
Hi Gábor,
Thank you for summarizing the discussion on IRC that I missed.
Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option
with a different effect? Or why do we want to conserve this option
name?
It appears to me simpler to give another name, for example
"--inputs-of". And it is
Hello guix,
Based on discussion on IRC the following plan for deprecation might work.
Comments are welcome:
1.
Make guix environment aware of an environment variable:
GUIX_ENVIRONMENT_DEPRECATED_AD_HOC
if this is defined, then fall back to the current behaviour.
Motivation: this would enable
44 matches
Mail list logo