> It is more "complicated" than that.  The detailed explanations are in
> the mega thread. :-) In short and from my understanding, going from
> "<profile>/manifest" to "-m manifest.scm" cannot be done in the general
> case because two concepts -- imperative vs declarative -- are not well
> aligned.  Pragmatically, it means that the result could be more than
> often unpractical with too much inferiors.  Well, only an
> "approximation" could be exported.

I went ahead and read through the threads that Pierre shared in a different
reply. For posterity and to collect my own thoughts, let me see if I can
distill the discussion so far:


The goal is to enable a profile to generate itself by reifying it into some
collection of code and data. Given such a tool, two places of use are proposed:

1) Implicitly, upon profile generation, outputting new files under /etc, or
2) Explicitly via a command like `guix package --export'.

It turns out that `guix system reconfigure' does some (most?) of this by
generating `/gnu/store/<hash>-provenance' and `/gnu/store/<hash>-channels.scm'
along with the profile itself.

Naively, a profile is just a sum of outputs; however, there are subtleties:

a) Provenance and inferiors
   For reproducibility, channel and revision information must be stored.

This is alreading in profile/manifest, however, so we already have the
necessary infrastracture in this regard.

b) The family of `--with-*' options to `guix package' means that provenance
   data itself is insufficient. Worse, `--expression' means that the collection
   of outputs might be specified with *arbitrary code*.

That said, the sum of provenance and command-line invocation should be
sufficient, no? If so, an extreme proof-of-concept reification could simply be
a bash script, something akin to the following:

    #!/bin/env bash
    guix time-machine -C <profile>/channels.scm -- \
    	guix package -p <profile> [<other options> ...]

c) Profile reifications need to be forward-compatible, meaning that future
   revisions of guix should produce the same profile as current/older ones
   given a reification.

This, of course, shows why the bash script idea is untenable, but with a more
reasonable Guile implementation, storing version information in the way of
`<profile>/manifest' neatly solves this issue.


Am I missing any major points? Almost surely there are minor ones I am
overlooking. Here are some of my questions:

Theorem: Given provenance data (e.g. a `channels.scm' file) and a command line
         invocation, profiles generation is deterministic.

Note that by "command line invocation" I am including any external files its
options reference as well.

Is this true at least mostly? Ludo mentions something about the "possibility of
multiple provenances" which I fail to grok. What is going on here? Does this
introduce a source of non-determinism for users building profiles? I.e. given
the right bash script, can a user reliably reproduce a given profile?

If the answer to the final question above is no, then that seems like a much
larger problem. However, if the answer is yes, then I would naively expect
profile reification to be mostly a matter of collecting together all the
sources of input that define a profile. Does forward-compatibility make this
less straightforward than I am thinking? What else am I missing?

> Sorry I am too lazy to search, but I think I remember that at the time
> Pierre sent -- probably in the mega thread :-) -- a small script to
> extract relevant information from <profile>/manifest; the preliminary
> for '--export-manifest'. :-)

Perhaps you are thinking of Pierre's script here?
https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00154.html


Cheers,