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: Wed, 07 Oct 2015 14:23:21 +0200 Message-ID: <87mvvu6f5y.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> <87wpv1tils.fsf@gnu.org> <87a8rwf2vl.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]:58830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zjnkl-0004OX-I5 for guix-devel@gnu.org; Wed, 07 Oct 2015 08:23:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zjnki-0008SL-Ch for guix-devel@gnu.org; Wed, 07 Oct 2015 08:23:27 -0400 In-Reply-To: <87a8rwf2vl.fsf@gmail.com> (Alex Kost's message of "Tue, 06 Oct 2015 18:11:42 +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-05 18:55 +0300) wrote: > >> Alex Kost skribis: >> >>> Ludovic Court=C3=A8s (2015-10-04 19:57 +0300) wrote: >>> > [...] >>>> In that case, I would suggest something based on the URL at point rath= er >>>> 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 writ= e a fake >> =E2=80=98sha256=E2=80=99 value just for the sake of being able to use th= at feature, >> which seems odd to me. >> >> See what I mean? How would you handle such a case? > > I don't see a problem here, since a fake sha256 may be any string,=20 Not really, since =E2=80=98base32=E2=80=99 is a macro that checks its argum= ent at expansion time. So in practice one cannot C-M-x a package with a random base32 string. > for example "" (an empty string). Also I believe people begin to > write a new package from some template, so you have a working skeleton > of future package with all required fields from the very beginning. > Then after filling an origin 'uri', you could "C-c . s" to download > the source and get its hash. Hmm. I=E2=80=99m skeptical. :-) What about, instead, providing an interactive function that would prompt for a URL, run =E2=80=98guix download=E2=80=99 on that, and emit an =E2=80= =98origin=E2=80=99 template at point with all the info? > Oh, now I see what you mean. Well, I don't know, I think if a user has > a habbit to check a signature, he will check it anyway; and if not, then > not. Besides, at first a packager needs to find an URL of the source > tarball, so he will meet a signature anyway, if it exists. So it's up > to him if he checks it or not. (Him or her.) I think we really want to give packagers a strong incentive to check signatures. Tools should make it easy to do that. >>>>> 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= would 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? > > Indeed, I agree. So if you don't mind the =E2=80=9Cdownload=E2=80=9D com= mand, then > since there will be 2 commands for working with the source of the > current package, what about the following key bindings for them: > > "C-c . s d" - to download the source (to know its hash) > "C-c . s b" - to build it Sounds good! Thanks, Ludo=E2=80=99.