David Thompson <dthomps...@worcester.edu> skribis: > Ludovic Courtès <l...@gnu.org> writes:
[...] >> 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")) Sounds good to me. (FWIW I’m not fond of the `(,gcc-toolchain "debug") notation that we also use in packages, but it has the advantage of being concise.) >>> 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. Yeah. And note that this can always be done from the wonderful guix.el (info "(guix) Emacs List Buffer"). Thanks, Ludo’.