Re: [PATCH] Emacs interface for Guix

[Alex Kost]

Ludovic Courtès (2014-08-12 18:19 +0400) wrote:

> Alex Kost <address@hidden> 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 <address@hidden>
>> 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 <address@hidden>
>> 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