Re: Store channel specification in profile

[Pierre Neidhardt]

We've made some progress on the topic during the Guix Days.

First, let's recall some of the use cases:

1. Allow the user to reproduce a profile easily.
2. Keep a profile specification under version control with least effort.
3. Eaysily interface with inferiors (e.g. build a profile with pkg1 and pkg2 
from
   two different Guix versions.)

   
Ideas that are not that good on second thought:

- Create a profile specification file from CLI options,
  like --export PROFILE or --convert MANIFEST.

  The problem is that those are extra steps that the user would have to run
  manually.  We can save those extra steps by dumping the specification file
  automatically into the profile.

The Plan©:

On every profile installation, we generate a "specifications.scm" file alongside
the internal "manifest".

Problems:

- There may be too many provenances, we need to add a CLI flag to
  ignore provenance.
  
- Too many provenances can be unusable (too slow to install, this happens when
  using imperative style).  Raise a warning, option to use latest Guix only.
  In all cases, we need an option to override all the provenance with a channel
  specification as per =guix describe -f channels=.

Proposed format for "specifications.scm": we can reuse
`specifications->manifest`.  Each entry is either or string, in which case it
acts as before, or a list, with the following self-explanatory elements:

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '(("my-package"
    #:outputs '("out")
    #:version "2.3"
    #:channel (channel
               (name 'guix)
               (branch "master")
               (url "https://git.savannah.gnu.org/git/guix.git";)
               (commit
                "704719edade1368f798c9301f3a8197a0df5c930")))
   ("my-package2")
   "old-style-package"))
--8<---------------cut here---------------end--------------->8---

   
A somewhat unrelated propostion: To avoid further confusion between the internal
"manifest" and the user-facing "--manifest", we could rename the internal
manifest to $profile/internal-maifest.

Thoughts?
Green light for a patch?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc
Description: PGP signature