From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:44263) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iougx-00008P-5q for guix-patches@gnu.org; Tue, 07 Jan 2020 14:39:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iougw-00045n-6W for guix-patches@gnu.org; Tue, 07 Jan 2020 14:39:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:43426) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iougw-00045e-2f for guix-patches@gnu.org; Tue, 07 Jan 2020 14:39:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iougw-0003Wc-04 for guix-patches@gnu.org; Tue, 07 Jan 2020 14:39:02 -0500 Subject: [bug#38769] [PATCH] import: Add importer for MELPA packages. Resent-Message-ID: From: Brett Gilio References: <87v9q1jjlf.fsf@zancanaro.id.au> Date: Tue, 07 Jan 2020 13:39:02 -0600 In-Reply-To: <87v9q1jjlf.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Sat, 28 Dec 2019 12:59:40 +1100") Message-ID: <87r20bqco9.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain 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: Carlo Zancanaro Cc: 38769@debbugs.gnu.org Carlo Zancanaro writes: > Hey Guix! > > I have for a while wanted to write an importer for MELPA packages that > reads from the MELPA recipe and constructs a Guix package. This is > primarily because the ELPA importer uses source tarballs, which we > can't rely on for MELPA because they remove old tarballs and upload > new ones whenever they rebuild the package. > > So, here is my importer! > > Probably the most controversial decision here is to always import the > current head that MELPA would build. This means that when you run > "guix import melpa" it gives you a package definition that should > correspond to what MELPA currently has. This may not correspond to a > release of the package, so we cannot easily give it a version, and > thus I put the current date into the version string. > > I imagine it would be possible to combine this importer with the > current ELPA one in some way, to use all the metadata provided by the > ELPA importer, but then generate an origin based on the MELPA recipe, > but that seemed more daunting to me than writing a new importer. > > Carlo > > Hi Carlo! Thanks for your contribution. I have not yet had a chance to look at it, but I agree that we /should/ combine this with the ELPA importer in its current tradition: `guix import elpa -a melpa`. That seems preferable to me, as it would avoid the need to deprecate a command flag in our UX. What do you think? -- Brett M. Gilio GNU Guix, Contributor | GNU Project, Webmaster [DFC0 C7F7 9EE6 0CA7 AE55 5E19 6722 43C4 A03F 0EEE]