From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 07 14:39:00 2020 Received: (at 38769) by debbugs.gnu.org; 7 Jan 2020 19:39:00 +0000 Received: from localhost ([127.0.0.1]:49399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iougu-0003WK-7n for submit@debbugs.gnu.org; Tue, 07 Jan 2020 14:39:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iougs-0003W7-EW for 38769@debbugs.gnu.org; Tue, 07 Jan 2020 14:38:59 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iougn-0003tv-9n; Tue, 07 Jan 2020 14:38:53 -0500 Received: from [2605:6000:1a0d:4c95::3d] (port=50916 helo=oryx) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iougm-0000JC-Km; Tue, 07 Jan 2020 14:38:52 -0500 From: Brett Gilio To: Carlo Zancanaro Subject: Re: [bug#38769] [PATCH] import: Add importer for MELPA packages. 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> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38769 Cc: 38769@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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]