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 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,
> 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
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
Hi zimoun,
zimoun 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
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,
> 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.
One remark:
I suggest the test to be "set to a non-empty string" resp. "unset or
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
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,
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
32 matches
Mail list logo
