Re: Emacs interface for Guix

[Alex Kost]

Ludovic Courtès (2014-07-20 23:47 +0400) wrote:

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

A directory name identifies the output but not a package definition.

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 will not be possible to install the exact package with
any UI, the only way is to use a guile REPL directly.

And I would say the names are not really package names, they are program
names, so with “guix package -i ...” a user installs a program, not a
particular package.  If there were a “unique-name” field, a user would
be able to install a real package: “guix package -i guile-base-2.0.11”.

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.  Anyway, if nothing can be done here, so be it; but any UI will be
confusing for these reasons.

P.S.  If not all packages are supposed to be installed by the end user,
perhaps it would be good to mark those somehow (for example to make an
optional “internal” field) and to add “--hide-internals” or
“--show-internals” option to “guix package” command.

If a user make his own package with the name that already exists, it is
his problem.  How is he going to distinguish these packages when he uses
“guix” script (or more generally any UI except of the guile REPL itself)?