Ludo',

I would find this quite helpful. The current "basic setup with manifests" only documents the trivial case. It would be quite nice to document best practices for custom UTF-8 profiles, system-dependent inclusion (should we silently skip packages on unsupported systems?), and updating package versions, inputs, and/or toolchain. And for the latter, what are the limits of the manifest as compared with cloning, modifying, building, and executing with "./pre-inst-env guix ..." (which loses reproducibility)?

Some background on that last thought: as Guix grows it becomes increasingly difficult to upgrade popular dependencies. I looked at upgrading 'fmt' and there was one dependent package that could not be upgraded, though not a package I needed. I'd like to be able to define an upgraded version of 'fmt' or 'boost' in my manifest and have it apply to the entire installation (profile or pack) rather than needing to modify specific packages with a with-input. Same for the toolchain, I think it would be nice to simply say "create this installation using gcc-toolchain" (the user default @11 rather than the system default @10) without needing any package transformations. And could one specify global build flags such as "-march=native"? Can one reach down into and modify commencement packages?

Greg