guix-devel
[Top][All Lists]
Advanced

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

Re: Emacs interface for Guix


From: Alex Kost
Subject: Re: Emacs interface for Guix
Date: Mon, 21 Jul 2014 22:46:13 +0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Ludovic Courtès (2014-07-21 20:04 +0400) wrote:

> Alex Kost <address@hidden> skribis:
>
>> I think current situation is very confusing to users.  A user can't even
>> install any package.  What if he wants to install “guile” from
>> “base.scm”?
>
> It’s possible, using ‘guix package -e’ (info "(guix) Invoking guix
> package").
>
> I think guix.el should be able to distinguish packages internally, so
> that when I choose, say, a specific “guile-2.0.11”, that’s really the
> one that gets installed (maybe it already does, I haven’t checked.)

No it doesn't and I don't see how it can be done.  If it were Guile
Emacs, it would be possible to distinguish packages internally, but all
I have now is name+version which is not unique.  Or maybe...

>> I strongly believe this is a problem.  You can see the packages that you
>> can't install or even worse “guix package --list-installed” may tell you
>> that you have several “foo-1.0:out” installed.  Actually when I saw the
>> packages with the same name/version the first time, I thought it's a
>> bug.
>
> I would say it’s a problem of the distro–i.e., the (gnu packages ...)
> modules–if several same-named packages are exposed to the user.  We’ve
> discussed several times the problem of having duplicates between
> base.scm and other modules, but I haven’t come to a satisfying solution.
>
> So I agree, these specific cases must be addressed somehow.
>
> However, it’s a fundamental feature of the package manager that packages
> (really: package records) can be freely created, and that the ‘name’
> field is just a hint.  Duplicates should remain rare in practice, but
> the UI must be prepared to deal with them IMO.
>
> WDYT?

... or maybe this: to fill some hash table or vhash or whatever with all
available packages after a repl is started, and use this storage with
unique keys to search/get packages instead of the ‘fold-packages’.  This
will allow to get and thus to install a particular package by its key.

I didn't think much about it, but right now this is the only workaround
I can imagine.  What do you think?




reply via email to

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