Re: Emacs interface for Guix

[ludo@gnu.org (Ludovic Courtès)]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2014-07-20 18:08 +0400) wrote:
>
>> Alex Kost <alezost@gmail.com> 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
package.

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

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

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

Thanks!

Ludo’.