guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Emacs interface for Guix


From: Ludovic Courtès
Subject: Re: [PATCH] Emacs interface for Guix
Date: Tue, 12 Aug 2014 21:50:00 +0200
User-agent: Gnus/5.130011 (Ma Gnus v0.11) Emacs/24.3 (gnu/linux)

Alex Kost <address@hidden> skribis:

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

[...]

>> 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.

Oops, fixed 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.

Cool.

>> 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?

Oh you’re right, currently upgrade and install are basically the same
thing.

>> 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.

The arguments should be the same as (or compatible) for ‘manifest-add’
and ‘manifest-remove’.

So the list of packages could be installed could be a list of (PACKAGE
OUTPUT) as you note.

The list of packages to upgrade could a list of (PACKAGE OUTPUT) as
well, computed by ‘guix package’ or guix.el.  (The difficulty here is
that (guix profiles) should not depend on (gnu packages).)

The list of packages to remove should be a list of <manifest-pattern>.

> So there will be ‘make-manifest-transaction’ function with #:install,
> #:upgrade, #:remove keys.  Do I understand it right?

Rather, use (define-record-type* <manifest-transaction> ...), so we can
then write:

  (manifest-transaction
    (install lst1)
    (remove lst2)
    ...)

>>   ;; 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?

No, it would just return the new manifest, built by successive calls to
‘manifest-add’ and ‘manifest-remove’.  Very simple.

The actual profile is still built with ‘profile-derivation’.

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]