Re: Reproducible profiles

[David Thompson <dthompson2@worcester.edu>]

Ludovic Courtès <ludo@gnu.org> writes:

> David Thompson <dthompson2@worcester.edu> skribis:
>
>> Lately I've been wanting to version control the list of packages that I
>> install in my user profile so that I can sync it amongst many machines.
>> So, I took a stab at adding a new '--apply' option to 'guix package'
>> that reads in a package list from a Scheme file and creates a new
>> generation of the profile with only those packages are installed.
>> Here's an example configuration:
>>
>>     (use-modules (gnu))
>>     (use-package-modules base less guile emacs admin ruby mail pumpio man)
>>     
>>     (list ruby
>>           coreutils
>>           less
>>           man-db
>>           notmuch
>>           guile-2.0
>>           emacs
>>           dmd
>>           offlineimap
>>           pumpa)
>
> Yes, that sounds very useful.
>
> As usual though, there’s the issue of multiple-output packages.  The
> above snippet is nice, but doesn’t allow you to specify a particular
> output of a package.

I left it out of my example, but I figured one could specify the output
like so:

    (list ruby coreutils `(,glib "bin"))

> What about instead requiring people to return a manifest:
>
>   (use-modules (guix profiles))
>   (use-package-modules base emacs guile)
>
>   (manifest (cons (package->manifest-entry gcc-toolchain "debug")
>                   (map package->entry
>                        (list gcc-toolchain emacs guile-2.0))))
>
> That means we’ll have to document (guix profiles).
>
> It’s more verbose than what you suggest, though.  If you insist ;-), we
> could allow a list of packages instead of a manifest, though I’d prefer
> not to do that.

Expecting a manifest always sounds good.  How about adding a convenience
procedure for the (map package->entry ...) pattern since I think it will
be the most common thing users will want to do?

    (packages->manifest (list guile-2.0 guile-opengl guile-sdl))

It could even support using other outputs like in that other example I
gave:

    (packages->manifest
      (list guile-2.0
            guile-opengl
            guile-sdl
            `(,gcc-toolchain "debug"))

>> Below is a naive patch that does the job, but is unideal because it
>> doesn't do some nice things like display the diff between generations
>> before building.
>
> For that you would need a procedure to infer the manifest transaction:
>
>   (manifests->transaction m1 m2)
>   ;; returns a <manifest-transaction>
>
> and then that could be passed to ‘show-manifest-transaction’.
>
> However, I’m not sure it’s very useful.  Perhaps it would be enough to
> write “installing new manifest from foo.scm with 42 entries.”
> WDYT?

Okay, I'll do that instead.  I would be interested in seeing what has
changed when I apply a new manifest, but it's probably not worth the
effort right now.

>> +         (option '("apply") #t #f
>> +                 (lambda (opt name arg result arg-handler)
>> +                   (values (alist-cons 'apply (load arg) result)
>> +                           arg-handler)))
>
> It would be better to delay loading until after arguments have been
> parsed, as in ‘guix system’.  The procedure to load the file should be
> similar to ‘read-operating-system’.

Sure.  The use of 'load' was a quick hack for this prototype. :)

> We’ll need documentation and tests, too.  :-)

Naturally.

Thanks, now I have enough direction to do another iteration. :)

-- 
David Thompson
GPG Key: 0FF1D807