From: Alex Kost <alezost@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Emacs interface for Guix
Date: Sun, 20 Jul 2014 20:52:37 +0400 [thread overview]
Message-ID: <87iomsq8fe.fsf@gmail.com> (raw)
In-Reply-To: <878uno9l7b.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 20 Jul 2014 16:08:40 +0200")
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
example now manifest may tell that "out" of a "guile-2.0.11" package is
installed but there are 2 "guile-2.0.11" packages out there and it's
impossible to distinguish those. And vice versa when I list available
packages I want to see my installed outputs only for the right packages,
not for all packages with the same name+version.
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?
>> 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!
It doesn't look good to me. As I said before, installed outputs should
“belong” only to a single package, which can be done only (IMHO) if
there will be a unique ID for a package definition.
>> 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.
Thanks.
next prev parent reply other threads:[~2014-07-20 16:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 5:59 Emacs interface for Guix Alex Kost
2014-07-16 14:18 ` Ludovic Courtès
2014-07-16 19:05 ` Alex Kost
2014-07-18 9:16 ` Ludovic Courtès
2014-07-19 7:51 ` Alex Kost
2014-07-19 16:28 ` Ludovic Courtès
2014-07-20 7:10 ` Alex Kost
2014-07-20 14:08 ` Ludovic Courtès
2014-07-20 16:52 ` Alex Kost [this message]
2014-07-20 19:42 ` Alex Kost
2014-07-20 19:47 ` Ludovic Courtès
2014-07-21 6:46 ` Alex Kost
2014-07-21 16:04 ` Ludovic Courtès
2014-07-21 18:46 ` Alex Kost
2014-07-21 21:26 ` Ludovic Courtès
2014-07-22 6:20 ` Alex Kost
2014-07-22 6:53 ` Taylan Ulrich Bayirli/Kammer
2014-07-22 8:41 ` Ludovic Courtès
2014-07-22 9:34 ` Alex Kost
-- strict thread matches above, loose matches on Subject: below --
2014-07-25 17:58 Alex Kost
2014-07-25 20:36 ` Ludovic Courtès
2014-07-26 17:44 ` Alex Kost
2014-07-28 10:15 ` Alex Kost
2014-08-11 20:54 ` Ludovic Courtès
2014-08-12 10:19 ` [PATCH] " Alex Kost
2014-08-12 14:19 ` Ludovic Courtès
2014-08-12 16:20 ` Alex Kost
2014-08-12 19:50 ` Ludovic Courtès
2014-08-13 6:57 ` Alex Kost
2014-08-13 16:03 ` Ludovic Courtès
2014-08-13 20:58 ` Alex Kost
2014-08-16 12:24 ` Ludovic Courtès
2014-08-16 13:07 ` Alex Kost
2014-08-19 21:00 ` Ludovic Courtès
2014-08-20 10:54 ` Alex Kost
2014-08-22 8:56 ` Ludovic Courtès
2014-08-22 12:44 ` Alex Kost
2014-08-27 8:34 ` Ludovic Courtès
2014-07-26 20:58 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87iomsq8fe.fsf@gmail.com \
--to=alezost@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).