What are your thoughs about eventually merging core with Guix?

[lucasew]

Question

Guix and Nix have a lot in common. Both have a base dir store (/{gnu,nix}/store), both have those drv files that basically run a command with args and env vars in a restricted environment.

It seems natural, at least for me, that in some way both can have a common project and basically a different stdenv and abstractions over it. Maybe the daemon and store parts could be shared and each project would only have it's own evaluator and nixpkgs and users could use Guix to use the same infrastructure Nix would use to build and remote build stuff.

What are your thoughs about eventually uniting this core in a common project?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[cafkafk]

As someone that was a part of re-adding Guix to nixpkgs, after Ludovic removed it, and someone that originally came from Guix, I think that it would be against the spirit of guix. Ludovic was very critical of many aspects of the Nix project, specially the module system and the at the time "Delft centric" development[1], which I do believe exists to this day (albeit Delft no longer being the center).

I think having to find inter project consensus, while on a very large scale valuable and useful, is not something that we should currently be focused on, we have much more pressing matters. Frankly, I think that if we don't address the prerequisites, we'd not be able to create a stable bridge between the project anyways (all to say, would be great, but we're not there...yet!).

I do think that we can learn a lot from Guix, not only how the Guix maintainers --- the top leadership positions --- are directly responsible for enforcing the code of conduct, or how it has managed to create a very calm and enjoyable community, but also on the technical side. Grafts are cool! And they're much better at communicating technical developments with the Guix blog. Hey, I've myself made my own guix weather for nix, just because I simply missed it too much as a former Guix user.

I think it's good to create mindshare between the projects, I know that when I was in Guix spaces, most people didn't know what those Nix people were doing with "those flake things". I also know that the Guix people are probably apprehensive about mingling with us given how we've had so much turmoil in recent past. Let's become the kind of project that can create those kinds of bridges, and the kind of project that inspires other projects confidence in investing that kind of effort into shared compatibilities, and create an ecosystem that supports the conditions for such efforts to occur. But I wouldn't push this top down, I think the people that are willing to put in that effort should decide when the time is right for creating said bridges, and lead those efforts themselves (with the support of the project and steering committee no less).

[1]: See this mail on the nix-dev mailing list for instance https://marc.info/?l=nix-dev&m=139641572912409&w=2

[mschwaig]

As you are probably aware, Guix got started as a fork of Nix.
I think Guix and Nix can still share the same store. Not breaking that kind of compatibility needlessly, I think is a good goal. Exchanging ideas and talking to each other is a good idea.

But to make it a priority to preserve this status quo or try to get rid of discrepancies that were introduced over time, in an effort to eventually merge the two projects again, is not a good or realistic goal. Both projects came up with good ideas after the split, and are still pursuing good ideas, which is simply more important than keeping the two projects in line with each other.

The shared technical primitives underlying both projects are quite fundamental, so maybe eventually we will be able to abstract away the differences and move closer together again that way, even if we are increasingly diverging right now.

[tomberek]

The Nix team has explicitly taken steps to split up the implementation to allow such a re-merging and reuse. There is an approved RFC and at this point we have the split not only as a library but as a separate derivation. These technical steps prove that it is viable. The C-API also allows easier usage of the Store layer as a library, thus we are in a good position to making our library more appealing for Guix to use directly.

I'll add that I think we can also inspire non-Nixpkgs, non-Nix-language and non-packaging usage of the Store layer for many other situations requiring distribution of data and software. I'd love to see libstore used in other ecosystems.

[doronbehar]

I agree with what the others said that this is a nice-to-have goal that should not be prioritized, as our other issues are much more pressing. However I completely endorse sharing copying from them the binary seed and in general their bootstrap method, something that had a lot of progress in the last year thanks to work by @emilytrau. I don't know exactly what is the state of these efforts at the moment, but it proves the point that forks have a positive influence on the project that they were forked from.

[roberth]

I support the componentization of Nix.
It solves unique problems in what's currently a fairly monolithic product, in a single repo, with somewhat of a single team and community responsible for maintenance and innovation.
I would support further componentization of Nix, which would allow not just for better ownership and innovation in those components, but also allow those components to be reused in Nix-like implementations such as Guix.
We shouldn't have to push Guix to adopt our libstore; we could make it excellent and then it's up them to make the call, and we should support them if they choose to adopt it.

I believe this is a good strategy regardless of what Guix wants, because it allows to grow a community of multiple tools that benefit from well maintained components, and it allows more radical innovation without having to fork everything.

[proofconstruction]

In fact, this is precisely the motivation behind RFC 134!

[Infinidoge]

I think it would be great to make the core of Nix independent of a lot of the Nix-centered supporting components. A big dream of mine is to work on making a more user-friendly language for the Nix package manager that makes it easier to make bigger projects without running into the many, many paper cuts and razor blades littering the ecosystem. A language-independent core would make this a much more feasible pursuit. A componentized Nix would, ideally, make it possible to mix different languages (and perhaps even package managers) around a central shared core, which I think would be fantastic.

However, I don't think that a priority should be made with regards to Guix specifically. Guix and GNU as a whole have a lot of stipulations and baggage that can make it harder to collaborate, so I don't see it as a worthwhile priority to focus on them specifically.