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

[Chris Marusich]

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?

[Ludovic Courtès]

Hello!

Post by Chris Marusich
https://nixos.org/nix/manual/#ssec-relnotes-2.0

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

Post by Chris Marusich
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.

Post by Chris Marusich
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.

Post by Chris Marusich
Can we take inspiration from any of the non-daemon features and use
them in Guix?

Definitely.

Post by Chris Marusich
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’.

[Mark H Weaver]

Post by Ludovic Courtès

Post by Chris Marusich
https://nixos.org/nix/manual/#ssec-relnotes-2.0

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

Post by Chris Marusich
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.

[...]

Post by Ludovic Courtès

Post by Chris Marusich
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

[Nils Gillmann]

Post by Chris Marusich
Hi,
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.