hello everyone, it's my first mail here, so let me briefly into myself: i'm a long-time lisper (mostly CL, i'm new to Scheme, although i worked on a scheme-like tiny lisp: https://github.com/attila-lendvai/maru). i'm coming over from NixOS after a few months of loving it as a user, but hating it as a developer. i have packaged bee for NixOS (a client of https://www.ethswarm.org/ written in go), but i got tired of the random, undebuggable obstacles of Nix, especially the implementation of the NixOS module system.
bee depends on go-ethereum (it uses its clef binary to manage the ethereum keys). so, regarding go-ethereum, i've seen this: [https://issues.guix.gnu.org/43872](https://issues.guix.gnu.org/43872#3) the initial conclusion was that the proper way to package a go project is to package the pinned transitive closure of every dependency. there's a go importer now, which is functional/hackable enough that this is not a hopeless task, but... i'm doubtful that it's a good idea to multiply the number of Guix packages by such an endeavor... :) then Helio Machado proposed something smarter in a later comment: https://issues.guix.gnu.org/43872#3 IIUC, he proposes a way to instead use the go module system to download all the dependencies, and yet authenticate all the downloaded go code. his work is not merged yet, and i think it's not even ready for merging yet. now, i'm rather motivated to work on this, maybe even willing to use the go importer and add countless pinned go packages... but is that desirable? is that the ultimate solution/goal? or should i wait until Helio's clever hack is merged? or shall i try to finish up his hack to be merge-ready? i'd really appreciate some guidance and/or coordination regarding where i should put my energy. - attila PGP: 5D5F 45C7 DFCD 0A39 PS: even though Guix has more rough edges from a user perspective, it feels much more natural with my developer hat on. thank you for that experience!
