Re: Emacs interface for Guix

[Alex Kost <alezost@gmail.com>]

Ludovic Courtès (2014-07-18 13:16 +0400) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2014-07-16 18:18 +0400) wrote:
>
> [...]
>
>>> That’s because it’s rebuilding most of the modules, AFAICS.  Perhaps
>>> ‘geiser-guile-load-path’ needs to be augmented to avoid that?
>>
>> Do you mean some guix directories should be added to that var?
>
> Yes.
>
>> But how to know the paths before starting guile?  Can't the default
>> paths be changed during "./conigure"-ing?
>
> Right.
>
> Actually I think eventually (i.e., soon ;-)) we should add guix.el to
> the Guix repo.  Among other things, that means that the Scheme code for
> guix.el can be easily kept in sync with the (guix ...) API, which is
> more difficult otherwise.

It would be great!  I think the main features should be finished soon:
now I'm adding support for displaying info about installed outputs, and
then only implementing actions (installing/deleting) will be left.

> Once guix.el is in the repo, we can use substitutions as for
> guix/config.scm to get the right directory names.
>
> In addition, note that ‘guix pull’ populates ~/.config/guix/latest, so
> this should come first in the search path (see scripts/guix.in on how it
> fiddles with search path.)
>
> WDYT?

Thanks, I finally realized why the paths should be augmented (I'm
getting experience with guix during working on guix.el :)).

Also I have a question: is there such thing as “obsolete package”?
AFAIU after ‘guix pull’, a user can still have old versions of packages
installed that don't exist in the new guix anymore.  I.e. after that
some packages from the current manifest cannot be found with
‘(find-packages-by-name "foo" "<old-version>")’.  Am I right?

> Thanks,
> Ludo’.

--
Alex