On Mon, 13 Jan 2020 at 15:59, Pierre Neidhardt <m...@ambrevar.xyz> wrote: > > If I understand correctly, it's because of the manifest files need > information like the store path and the propagated inputs, which are too > inconvenient for a user-facing "specification file."
Hum? I am not convinced yet. :-) For example, the record <package> contains the field "outputs" but some packages do not use it; e.g., "xmag". Same for "native-inputs", etc. To me, the aim is to have something compliant between <profile>/manifest and --manifest. And compliant does not mean that <profile>/manifest is the entry point for the user specifications. What I find a bit odd is: today, --manifest accepts a DSL and Guix outputs to <profile>/manifest another DSL. Both are restricted tiny DSL. And from all the recent discussions about manifests and so on, I find appealing to extend the DSL of --manifest and use a subset to write <profile>/manifest. I do not know. Cheers, simon
