Ludovic Courtès (2014-08-12 18:19 +0400) wrote:
> Alex Kost <alez...@gmail.com> skribis:
>
>> Thanks for pointing. I've never contributed to a real project, so I
>> don't know the rules actually :)
>
> No problem. :-) There might still be unwritten rules, but we can fix
> that as we go.
>
>> From af4b8495969d70d59aa9f3f296628daeaf80b0d2 Mon Sep 17 00:00:00 2001
>> From: Alex Kost <alez...@gmail.com>
>> Date: Tue, 12 Aug 2014 12:32:16 +0400
>> Subject: [PATCH 1/2] profiles: Add 'manifest-add'.
>>
>> * guix/profiles.scm (manifest-add): New procedure.
>> * tests/profiles.scm (guile-1.8.8): New variable.
>> ("manifest-add"): New test.
>
> Perfect. I’ve pushed it, followed by a patch that changes
> guix/scripts/package.scm to use ‘manifest-add’ (comments welcome.)
Thanks, you forgot to delete ‘same-package?’ from ‘guix-package’
[‘process-actions’] in your commit – it is a part of ‘manifest-add’ now.
>> From 5fd45b3f4216921837f522d56b20c4be0a58fe8e Mon Sep 17 00:00:00 2001
>> From: Alex Kost <alez...@gmail.com>
>> Date: Tue, 12 Aug 2014 13:54:23 +0400
>> Subject: [PATCH 2/2] guix package: Add 'process-package-actions'.
>>
>> * guix/scripts/package.scm (process-package-actions): New procedure.
>> (guix-package): Use it.
>> [ensure-default-profile]: Move to top-level.
>> [substitutes?]: New variable.
>> [same-package?]: Remove.
>> (options->installable, options->removable): Change according to
>> 'process-package-actions'.
>
> This patch would need to be rebased on top of f48624f.
>
> Were you planning on using ‘process-package-actions’ in the Emacs
> interface?
Yes, actually I've been using that function for a couple of weeks, I
just didn't update "guix.el" repo for that. But your suggestion below
is definitely better.
> That seems like a coarse-grain and clumsy interface. Perhaps there are
> tinier parts of it that could be moved to (guix profiles)? For
> instance, there’s no ‘manifest-upgrade’ at the moment.
I think ‘manifest-add’ already does what ‘manifest-upgrade’ would do: it
replaces entries with the same name. So if there is installed
“guile-2.0.11:out” and a user installs “guile-1.8.8:out”, the previously
installed guile is removed from manifest. I thought it's intended
behaviour and that's why ‘options->installable’ combines “to-install”
and “to-upgrade” options. Could you explain what ‘manifest-upgrade’
should do?
> What about introducing a <manifest-transaction> type that would contain
> a list of packages to install, to remove, and to upgrade, and we could do:
I think only “install” part should contain a list of packages (or
(PACKAGE OUTPUT) things). Upgrading and removing can be performed on
obsolete packages, so only a package specification of an installed
package is known in such cases. Perhaps any pattern (package (with
"out" output), (package output), name specification) should be accepted.
So there will be ‘make-manifest-transaction’ function with #:install,
#:upgrade, #:remove keys. Do I understand it right?
> ;; Show what will/would be installed, removed, etc.
> (show-transaction manifest transaction #:dry-run? bool)
>
> ;; Do the installation/removal/upgrades listed in TRANSACTION, and
> ;; return the new manifest.
> (manifest-perform-transaction manifest transaction)
So ‘manifest-perform-transaction’ will open connection? If so,
shouldn't it accept '#:dry-run' and '#:use-substitutes?' keys?
--
Alex
