<ngz>Let's send this on email@example.com then.
<mb[m]1>Now, an even better approach than wrapping would be to substitute the "python" invokation with something such as (string-append (assoc-ref inputs "python") "/bin/python"), although that's not always easily feasible.
<lfam>It's not terribly different from building GCC, right? ;)
<davexunit>so our cargo package has to download all the source code to all the dependencies separately, generate checksums for them, and then write out a .cargo/config file so that the bootstrap cargo won't try to access the network
<kmicu>Nixpkgs is MIT so corporations use it, write blogs, users write blogs b/c reproducible binaries or FHS wrappers let them play games or use Firefox Quantum. It is not surprising they get more attention.
<kmicu>(It is like Arch vs Parabola, Ubuntu vs Trisquel and so on.)
<lfam>I think it's not exactly comparable to those distro pairs
<kmicu>There is ~100 \\bnix_.* variables in Guix source and you say 'Guix shares essentially 0 code with Nix'. And you still need that Nix leftovers to *compile* Guix.
<lfam>Hi, there is no need for this discussion to become an argument. We have a cordial relationship with the Nix project and do not hide that we still use some Nix code
<lfam>My understanding is that our implementation is sui generis from package to derivation, and for all the user-facing code.
<janneke>Here, here. Moreover, the main reason that we work to replace the Nix C++ code with Guile is a pragmatic one, it will enable some critically nice features.
<lfam>Going from derivation to store object, we use the daemon code forked from Nix. I don't understand that level very well, so I'm not sure exactly what does what down there
<kmicu>I understand all of that. I am familiar with Nix code base and Guix code base. I migrated almost all my hardware to Guix(SD). But pretending that Guix is special or novel will always trigger me. Guix still uses http://hydra.gnu.org/