From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Emacs interface for Guix Date: Sun, 20 Jul 2014 21:47:15 +0200 Message-ID: <874myb95j0.fsf@gnu.org> References: <87zjg9rgih.fsf@gmail.com> <871ttlgzfl.fsf@gnu.org> <87vbqxqg3n.fsf@gmail.com> <87ha2fm3gk.fsf@gnu.org> <87r41hrdks.fsf@gmail.com> <8738dxe2jq.fsf@gnu.org> <87mwc4qzd5.fsf@gmail.com> <878uno9l7b.fsf@gnu.org> <87iomsq8fe.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8x4y-0005ew-Mp for guix-devel@gnu.org; Sun, 20 Jul 2014 15:47:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X8x4p-0002IN-JQ for guix-devel@gnu.org; Sun, 20 Jul 2014 15:47:28 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:35896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X8x4p-0002IA-2g for guix-devel@gnu.org; Sun, 20 Jul 2014 15:47:19 -0400 In-Reply-To: <87iomsq8fe.fsf@gmail.com> (Alex Kost's message of "Sun, 20 Jul 2014 20:52:37 +0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Alex Kost Cc: guix-devel@gnu.org Alex Kost skribis: > Ludovic Court=C3=A8s (2014-07-20 18:08 +0400) wrote: > >> Alex Kost skribis: >> >>> Yes, that's what concerned me since the very beginning =E2=80=93 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 >>> =E2=80=98name-version=E2=80=99 spec to "identify" a package, informatio= n 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=E2=80=99t guarantee that there=E2=80=99s a single p= ackage 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 =E2=80=98get-package-by-id=E2=80=99 function that wi= ll 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 =E2=80=9Cpostfix=E2=80=9D = field to > record, so that a combination =E2=80=9Cname+version+[postfix]= =E2=80=9D will be > unique and will be returned by =E2=80=98package-id=E2=80=99 like this: > > (package-id #) =3D=3D> "g= uile-2.0.11" > (package-id #) =3D=3D> "g= uile-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=E2=80=99s 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=E2=80=99= re the same. When they don=E2=80=99t all you know is that it=E2=80=99s a diff= erent package. Remember that packages can be generated programmatically (see =E2=80=98static-package=E2=80=99 & co.), and they users can install package= s from their own recipes. There=E2=80=99s 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 =E2=80=9Clist=E2=80=9D and especially =E2= =80=9Cinfo=E2=80=9D buffers >>> currently (I have updated the repo). >> >> Looks good to me! ... that=E2=80=99s 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=E2=80=99m 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=3D0 >> ;;; or pass the --no-auto-compile argument to disable. >> ;;; compiling /data/src/guix.el/guix-helper.scm > > A lot? Hm, for me =E2=80=9Cguix-helper.scm=E2=80=9D was the only file th= at was compiled > as it was changed. Could you check that =E2=80=9CC-h v guix-directory=E2= =80=9D tells > you the proper directory? (for me it is "/home/alexx/.config/guix/latest" > now) Also check =E2=80=98%load-compiled-path=E2=80=99 in the =E2=80=9C*G= uix REPL*=E2=80=9D 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 =E2=80=98guix-directory=E2= =80=99 is set to.) I can=E2=80=99t seem to reproduce the problem now, so probably the problem = was between keyboard and chair. :-) Thanks! Ludo=E2=80=99.