[Top][All Lists]

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

Re: Emacs interface for Guix

From: Ludovic Courtès
Subject: Re: Emacs interface for Guix
Date: Sun, 20 Jul 2014 21:47:15 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

Alex Kost <address@hidden> skribis:

> Ludovic Courtès (2014-07-20 18:08 +0400) wrote:
>> Alex Kost <address@hidden> skribis:
>>> Yes, that's what concerned me since the very beginning – unique entities
>>> should have unique identifiers, i.e. ideally there should be an
>>> easy-to-get ID for every package.  But as I'm using a non-unique
>>> ‘name-version’ spec to "identify" a package, information about installed
>>> outputs is displayed for every matching package.
>> OK.  At the Scheme level, package objects are unique of course; but at
>> the UI level, we can’t guarantee that there’s a single package for each
>> name/version pair (and this is not even desirable, I think.)
> I don't say that name+version should identify a package, but I think it
> would be very convenient to have an ID for a package definition.  For


> What if to make some ‘get-package-by-id’ function that will always
> return a single package?  And there is no need to add IDs for all
> package definitions, as most of them are identified with name+version
> already.  What I suggest is to add an optional “postfix” field to
> <package> record, so that a combination “name+version+[postfix]” will be
> unique and will be returned by ‘package-id’ like this:
>   (package-id #<package guile-2.0.11 gnu/packages/guile.scm>)  ==> 
> "guile-2.0.11"
>   (package-id #<package guile-2.0.11 gnu/packages/base.scm>)   ==> 
> "guile-2.0.11_base"
> And also to add this ID to the manifest entries.
> I believe all this will not break current functionality but it may be
> very useful.  What do you think?

I think it would be just another hand-maintained identifier database,
thereby suffering from the very same problems as name+version.

But there’s already a 100% unique identifier that can be relied on: the
directory name of outputs.  When the directory name(s) of an installed
package match that of a package from the distro, you can tell they’re
the same.  When they don’t all you know is that it’s a different

Remember that packages can be generated programmatically (see
‘static-package’ & co.), and they users can install packages from their
own recipes.  There’s no notion of having a central unique package

So I think the UI must be able to cope with that: it has package names
as nice human-readable identifiers, but it cannot map back from an
installed package to its recipe and...

>>> You may look at:
>>>   M-x guix-search-by-name guile-2.0.11
>>> to see how it looks like in a “list” and especially “info” buffers
>>> currently (I have updated the repo).
>> Looks good to me!

... that’s why I say it looks good to me.  :-)

>>> Also I made some changes for augmenting paths, so please report if
>>> something does not work.
>> I’m still seeing a lot of these at the top of *Guix REPL*:
>> ;;; note: source file /data/src/guix.el/guix-helper.scm
>> ;;;       newer than compiled 
>> /home/ludo/.cache/guile/ccache/2.0-LE-8-2.0/data/src/guix.el/guix-helper.scm.go
>> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>> ;;;       or pass the --no-auto-compile argument to disable.
>> ;;; compiling /data/src/guix.el/guix-helper.scm
> A lot?  Hm, for me “guix-helper.scm” was the only file that was compiled
> as it was changed.  Could you check that “C-h v guix-directory” tells
> you the proper directory? (for me it is "/home/alexx/.config/guix/latest"
> now)  Also check ‘%load-compiled-path’ in the “*Guix REPL*” buffer, please.

The only difference between %load-compiled-path in my *Guile REPL* and
that in *Guix REPL* is that the latter adds this
"/home/ludo/.config/guix/latest" (which is what ‘guix-directory’ is set

I can’t seem to reproduce the problem now, so probably the problem was
between keyboard and chair.  :-)



reply via email to

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