On Sun, 27 Oct 2024 20:26:03 +0000 Sharlatan Hellseher wrote: > Thanks for the initiation of unbundeling process for materbridge! Thanks a lot for the review. > A general comments for Golang packages which is just final binary, you > may apply "#:install-source? #f" parameter which mean do not place > source of the project into store and just move produced binary. Thanks, I'll do that in a newer patch. > Also for the final binary all build inputs may be placed to > "native-inputs" they will never be used elsewhere after the install > phase. Right, I just copied a bit what was done in the example I followed, so that might need to be fixed as well. Using inputs didn't look right to me but it was done in this way so I assumed that there was a good reason for it (I tried unbundling long time ago and it didn't work at the time, but maybe I was just unlucky). > While you are keen to unbundle let's pick up as many as we can. You > may also add some other inputs which are available already: I was already unsure about the patch I sent. In the v2 should I do it all at once in a single patch or should I split the work across multiple patches? The advantage of the former is that it becomes easier to bisect issues. The downside is that if the granularity is too small, I fear that we'll end up with hundreds of patches. So I also think it's a good idea to agree on how to make these changes before doing more and more patches. For instance you could validate one patch (without necessarily pushing it) so I could use that as a blueprint for the next ones and not have to redo all the work for so many patches. Here I picked something in between where I grouped the unbundling of dependencies by selecting something they had in common, but I've no idea if it's the right way to do it. Also note that I ran the resulting binary, but without feeding it a configuration. I'll do a more complete test later on as tests are quite expensive: I need to install Guix on the production server, update it, build the matterbridge package, and uninstall guix after that to reduce the attack surface. > - filippo.io/edwards25519 > - go.uber.org/multierr > - gopkg.in/ini.v1 > - gopkg.in/natefinch/lumberjack.v2 > - gopkg.in/natefinch/lumberjack.v2 > - gopkg.in/yaml.v2 > - gopkg.in/yaml.v3 > - google.golang.org/protobuf > - github.com/hashicorp ;; all of them are available > - github.com/golang/protobuf > - github.com/fatih/color > - github.com/google/uuid > - github.com/gorilla/websocket > - github.com/pkg/errors Thanks, I found some of them like the protobuf one but I didn't add them in my patch yet. > Basically we targeting to have just the first level of dependentices > in "native-inputs" as seen in > . OK, I didn't look at that yet, I just started looking at what was in vendor/ with a script and made a patch with the group that is closer to the language (golang). > Please take a look if removing them from vendor and adding them to > native-inputs still keeps the build green. Thanks for the additional list, I'll definitely do that. Denis.