You say nix, I say guix: Nix 2.0 and Guix

You say nix, I say guix: Nix 2.0 and Guix

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hi,

On February 22nd, Nix 2.0 was released:

https://nixos.org/nix/manual/#ssec-relnotes-2.0

It contains a lot of interesting new features.  Are there any plans to
merge some of the nix-daemon changes into our guix-daemon?  Is
compatibility with the nix-daemon a goal of the Guix project?  Can we
take inspiration from any of the non-daemon features and use them in
Guix?  Conversely, is there anything we can upstream to Nix that they
might find useful?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: You say nix, I say guix: Nix 2.0 and Guix

[Ludovic Courtès]

Hello!

Chris Marusich <cmmarusich@gmail.com> skribis:

> On February 22nd, Nix 2.0 was released:
>
> https://nixos.org/nix/manual/#ssec-relnotes-2.0

Very nice work.  It looks like the CLI is closer to that of Guix now.  :-)

> It contains a lot of interesting new features.  Are there any plans to
> merge some of the nix-daemon changes into our guix-daemon?

Why not?  What did you have in mind?  One thing we discussed long ago
was the idea of keeping signatures in the store database, and I think
Nix 2.0 does that.  That’s something we could borrow.

> Is compatibility with the nix-daemon a goal of the Guix project?

I’ve come to the conclusion that it’s not a worthy goal, as in, it would
cost more than it’s worth.  guix-daemon is already incompatible with
nix-daemon on a few things, such as the “builtin:download” derivation
builder.

> Can we take inspiration from any of the non-daemon features and use
> them in Guix?

Definitely.

> Conversely, is there anything we can upstream to Nix that they might
> find useful?

Changes in the daemon are pretty much the only thing we could upstream,
and I used to do exactly that.  At some point I decided to stop
following closely upstream and allow ourselves to change the daemon as
we see fit.  As a result, you may find that not every change that we
make to our nix/ directory is directly applicable to current Nix.

I’m also hopeful that we can move to a Guile-based daemon in the future.

Overall, I think Nix and Guix still have a lot to share, probably not in
terms of code, but at least in terms of design, features, and ideas.
The discussions with Eelco at the Guix Workshop demonstrated that!

Ludo’.

Re: You say nix, I say guix: Nix 2.0 and Guix

[Nils Gillmann]

Chris Marusich transcribed 1.4K bytes:
> Hi,
> 
> On February 22nd, Nix 2.0 was released:
> 
> https://nixos.org/nix/manual/#ssec-relnotes-2.0
> 
> It contains a lot of interesting new features.  Are there any plans to
> merge some of the nix-daemon changes into our guix-daemon?  Is
> compatibility with the nix-daemon a goal of the Guix project?  Can we
> take inspiration from any of the non-daemon features and use them in
> Guix?  Conversely, is there anything we can upstream to Nix that they
> might find useful?
> 
> -- 
> Chris


What could be reused in my opinion, from the changelog and not simply code:

* Silent builds / operations by default.
  We already have the option for this, without the progress report iirc.
  Since only developers and Build machines are interested in the verbose
  building output, we could adjust the defaults to this?

* specific example in the --help output of the functions?
  At the moment we have generic examples. Something that tells
  people how to install for example libreoffice is much closer
  to their reality when they are lost (judging from my group of
  friends who are technically skilled but still not Guix current
  user group.).

* nix why-depends, nix path-info are nice.

* do we have a progress report on guix gc operations for optimizing?

* nix ls-store and nix ls-nar look interesting.

* "In Linux sandbox builds, we now use /build instead of /tmp as the temporary build directory. This fixes potential security problems when a build accidentally stores its TMPDIR in some security-sensitive place, such as an RPATH."
  This is a very interesting development. I wanted to move TMPDIR for specific cases anyway
  but did not consider yet another directory in the root. I would've used another location.

Re: You say nix, I say guix: Nix 2.0 and Guix

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> On February 22nd, Nix 2.0 was released:
>>
>> https://nixos.org/nix/manual/#ssec-relnotes-2.0
>
> Very nice work.  It looks like the CLI is closer to that of Guix now.  :-)
>
>> It contains a lot of interesting new features.  Are there any plans to
>> merge some of the nix-daemon changes into our guix-daemon?
>
> Why not?  What did you have in mind?  One thing we discussed long ago
> was the idea of keeping signatures in the store database, and I think
> Nix 2.0 does that.  That’s something we could borrow.

[...]

>> Conversely, is there anything we can upstream to Nix that they might
>> find useful?
>
> Changes in the daemon are pretty much the only thing we could upstream,
> and I used to do exactly that.  At some point I decided to stop
> following closely upstream and allow ourselves to change the daemon as
> we see fit.  As a result, you may find that not every change that we
> make to our nix/ directory is directly applicable to current Nix.

One possible complication with exchanging code with nix-daemon is that a
few years ago, nix-daemon apparently switched to a multithreaded model,
whereas guix-daemon deliberately avoids threads in the daemon.  See:

  https://lists.gnu.org/archive/html/guix-devel/2014-12/msg00363.html

That said, I haven't followed Nix development, so I don't know what has
happened with nix-daemon since then, nor how much this would affect code
sharing in practice.

      Mark