From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxexa-0007Ze-Qz for guix-patches@gnu.org; Thu, 28 Sep 2017 15:59:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxexa-0002tz-03 for guix-patches@gnu.org; Thu, 28 Sep 2017 15:59:02 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:56697) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dxexZ-0002tr-S1 for guix-patches@gnu.org; Thu, 28 Sep 2017 15:59:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dxexZ-00048y-Kj for guix-patches@gnu.org; Thu, 28 Sep 2017 15:59:01 -0400 Subject: [bug#28251] [PATCH 0/3] Add generic JSON importer Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170827155820.28812-1-rekado@elephly.net> <87bmmu5t4d.fsf@gnu.org> <1033407664.20475.1506597823791.JavaMail.sas@[172.25.246.172]> Date: Thu, 28 Sep 2017 21:58:34 +0200 In-Reply-To: <1033407664.20475.1506597823791.JavaMail.sas@[172.25.246.172]> (Ricardo Wurmus's message of "Thu\, 28 Sep 2017 13\:23\:40 +0200") Message-ID: <87efqqlhn9.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ricardo Wurmus Cc: 28251@debbugs.gnu.org Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: > >> I wonder if we could further simplify the =E2=80=9Csource=E2=80=9D part,= like allowing >> (maybe optionally) for: >> >> "source": "mirror://gnu=E2=80=A6" >> >> and then letting the importer download the thing and fill in the hash. >> Likewise for a Git checkout: >> >> "git": { "commit": "cabba9e"; "url": "=E2=80=A6" }; >> >> Thoughts? > > I have added support for a simple source string as in the first example. > I left the support for a direct translation of origin expressions > unchanged, because I=E2=80=99m not sure yet how to express this. > > So, right now we can do either > > "source": "mirror://gnu/hello/hello-2.10.tar.gz", > > or > > "source": { > "method": "url-fetch", > "uri": "mirror://gnu/hello/hello-2.10.tar.gz", > "sha256": { > "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i" > } > } > > I=E2=80=99m open to simplifying this further. What do other people think? That sounds good to me. One important consideration is to have a format that is future-proof, which is probably the case here. We could perhaps add a =E2=80=9Cformat-version=E2=80=9D field in the JSON input to be on the safe = side, though it would defeat the whole simplification. (In other news, I=E2=80=99ve been considering the implementation of an =E2=80=9Cupstream=E2=80=9D importer, where =E2=80=9Cguix import upstream UR= L=E2=80=9D would return a package template as complete as possible.) Thanks, Ludo=E2=80=99.