Hi Denis, Adding to Andreas's thesis - it's hard to be the first =) and extending your concern - start with small; small series, small contribution, small steps, but be persistent in your efforts and keep the attitude (refering to Chris Hadfield's "An Astronaut's Guide to Life on Earth").
To ease you first step - just don't think about overwhelming complexity of bringing all 500+ (or more) packages into Guix at one go, start with short logical series say 5-10. Contribution in small series is, personally as a commiter, easy to review and merge quickly than wait for months when someone has a free time slot to review long chain (I try to find time between family duties and main job). Sending small series from larger count of involved contributors makes propagation of new packages much faster, e.g. you may pack 10 projects which will be in inputs for others sent by someone else etc. Take a look at the current effort of unbundle (gnu packages ipfs) - kubo. Bit by bit and we nearly unweaved the rainbow. --8<---------------cut here---------------start------------->8--- I've also no idea about how many go packages use bundled dependencies, so maybe if there is a way to somehow un-bundle part of the dependencies it could be a road to improve the situations as the maintenance the dependencies shared by many go packages could be shared somehow (assuming people do check that when updating things it doesn't break other packages). --8<---------------cut here---------------end--------------->8--- This part may be addressed in go-build-system with default phase, removing "vendor" directory - the only way to bundle in Go ecosystem. --8<---------------cut here---------------start------------->8--- Another issue is that all that is statically built but that's part of the default go compiler if I understood well, though given how Guix works, it might easier to somehow use shared libraries (compared to more standard distributions) if some compilers that support that since we don't need very strict/strong ABI guarantees with Guix, and thanks to that, reduce build times and resources consumption (like RAM, space, etc). --8<---------------cut here---------------end--------------->8--- There is nearly 0 linking to any libraries in Go ecosystem, each "library" is a bunch of code which compiler use to build the final binary, nothing is linked in terminology of C/C++ e.g. - library from the Golang point of view is a source code (text, not blob) --8<---------------cut here---------------start------------->8--- What would be the quality of the maintenance in the long run with about 500 packages to update? --8<---------------cut here---------------end--------------->8--- No need to update all the chain to make a fresh version of final binary in most cases it's enough to refresh 2-3 packages to make build/test green. Golang does not implement any pin mechanics for dependencie versions like Rust/Cargo does. So... let's get packages be packed and review in small consistence flow, keep your altitude and let the curiosity be with you! Keep hacking. -- Oleg
signature.asc
Description: PGP signature
