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