From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'. Date: Mon, 05 Oct 2015 17:55:59 +0200 Message-ID: <87wpv1tils.fsf@gnu.org> References: <1443791046-1015-1-git-send-email-alezost@gmail.com> <1443791046-1015-3-git-send-email-alezost@gmail.com> <87d1wvadw2.fsf@gnu.org> <87bnceah2e.fsf@gmail.com> <87r3la6077.fsf@gnu.org> <87eghalc7s.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]:33183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj87W-00005E-1x for guix-devel@gnu.org; Mon, 05 Oct 2015 11:56:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj87N-0007Yk-JW for guix-devel@gnu.org; Mon, 05 Oct 2015 11:56:08 -0400 In-Reply-To: <87eghalc7s.fsf@gmail.com> (Alex Kost's message of "Sun, 04 Oct 2015 21:28:55 +0300") 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 (2015-10-04 19:57 +0300) wrote: > >> Alex Kost skribis: >> >>> Ludovic Court=C3=A8s (2015-10-03 23:35 +0300) wrote: >>> >>>> Alex Kost skribis: >>>> >>>>> * emacs/guix-devel.el (guix-devel-setup-repl): Use (guix packages) mo= dule. >>>>> (guix-devel-download-package-source): New command. >>>>> (guix-devel-keys-map): Add key binding for it. >>>>> * doc/emacs.texi (Emacs Development): Document it. >>>> >>>> [...] >>>> >>>>> +(defun guix-devel-download-package-source () >>>>> + "Download the source of the current package. >>>>> +Use this function to compute SHA256 hash of the package source." >>>>> + (interactive) >>>>> + (guix-devel-with-definition def >>>>> + (guix-devel-use-modules "(guix scripts download)") >>>>> + (when (or (not guix-operation-confirm) >>>>> + (y-or-n-p (format "Download '%s' package source?" def)= )) >>>>> + (guix-geiser-eval-in-repl >>>>> + (format "(guix-download (origin-uri (package-source %s)))" >>>>> + def))))) >>>> >>>> What about instead building the =E2=80=98package-source-derivation=E2= =80=99 of the >>>> package? That way, that would do the exact same thing as =E2=80=98gui= x build >>>> -S=E2=80=99 and would work not only with =E2=80=98url-fetch=E2=80=99 b= ut also with the other >>>> things. >>>> >>>> WDYT? >>> >>> The goal of this command is to display a hash. >> >> So this would be something one would use as they write a package >> definition, to fill in the =E2=80=98sha256=E2=80=99 field, right? > > Exactly. For example, here is how I update a package using Geiser: > > - I modify its 'version' field, > - "C-M-x" to reevaluate the package definition, > - "C-c . s" to download the new source and show its hash, > - replace the old hash with the new one, > - and finally "C-c . b" to build the new version of package. OK, nice. >> In that case, I would suggest something based on the URL at point rather >> than the origin at point. > > It's neither URL at point, nor origin at point: it's like "C-c . b" but > to download the source of the current package definition instead of > building it. > > Also I don't understand how it can be based on the URL at point as > instead of the full URL, we have something like this: > > (uri (string-append "http://.../foo-" version ".tar.xz")) > > So currently to use "guix download", at first you need to manually > construct the full URL. I find this inconvenient, that's why I want to > have a command to download a source of the current package and to > display its hash. Yes, that make sense. The problem I had in mind was that, when writing a new package definition from scratch, you don=E2=80=99t know the SHA256 yet, but =E2=80= =98sha256=E2=80=99 is a required field of =E2=80=98origin=E2=80=99. So one would have to write a= fake =E2=80=98sha256=E2=80=99 value just for the sake of being able to use that = feature, which seems odd to me. See what I mean? How would you handle such a case? >> However, if this is =E2=80=9Ctoo convenient=E2=80=9D, I=E2=80=99m afraid= this would give an >> incentive to not check OpenPGP signatures when they are available. > > Sorry, I have no idea what it means :-( When upstream digitally signs its source code tarballs, packagers should check those signatures to authenticate the code they have. If the tool makes it too easy to fill out the =E2=80=98sha256=E2=80=99 fiel= d without going through the trouble of downloading the =E2=80=98.sig=E2=80=99 file an= d checking it, then people will have an incentive not to check those signatures. >>> At first I also thought about building a package source and then to >>> calculate the hash of the store file, but this way will lead to the >>> wrong hashes for "snippet"-ed origins. Or do I miss anything? >> >> Well, I think bindings for =E2=80=98package-source-derivation=E2=80=99 w= ould also be >> useful, but IIUC this is not what you had in mind. > > If you mean to make a command to build the current package source, it > can be done, although I don't see how it can be useful. It=E2=80=99s occasionally useful, similar to =E2=80=98guix build -S=E2=80= =99 or the =E2=80=9CShow=E2=80=9D button in package info buffers, except that it would operate directly on the package at point. WDYT? Thanks, Ludo=E2=80=99.