[bug#54393] [PATCH 0/2] Add 'guix manifest' to "translate" commands to manifests

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Greg Hogan <code@greghogan.com> skribis:

> 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.

OK.

> 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?

This—switching compiler tool chains and tuning for a CPU—is available as
package transformations:

  https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html

You can take advantage of those in your manifest using
‘option->transformations’:

  https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html#index-options_002d_003etransformation

The tentative ‘guix manifest’ and ‘guix package --export-manifest’
create that code snippet for you, as in this example:

  https://issues.guix.gnu.org/54393#2-lineno134

That’s the kind of thing I’d like to show in the “Writing Manifests”
section.

Tuning and switching tool chains will always happen through package
transformations.  In Guix, things have to be specified explicitly;
there’s no way you can stealthily change the meaning of the dependency
graph without changing it—unlike other tools in this area.  But that’s a
strength!  Now, we have to make it so that such changes can be done
conveniently, and package transformation options were introduced in this
spirit.

I hope that makes sense!

Ludo’.