GNU bug report logs - #38769
[PATCH] import: Add importer for MELPA packages.

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Christopher Baines <mail <at> cbaines.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#38769: closed ([PATCH] import: Add importer for MELPA packages.)
Date: Fri, 18 Dec 2020 12:41:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 18 Dec 2020 12:40:26 +0000
with message-id <87sg831e4l.fsf <at> cbaines.net>
and subject line Re: [bug#38769] [PATCH] import: Add importer for MELPA packages.
has caused the debbugs.gnu.org bug report #38769,
regarding [PATCH] import: Add importer for MELPA packages.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
38769: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38769
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Carlo Zancanaro <carlo <at> zancanaro.id.au>
To: guix-patches <at> gnu.org
Subject: [PATCH] import: Add importer for MELPA packages.
Date: Sat, 28 Dec 2019 12:59:40 +1100

[Message part 3 (text/plain, inline)]

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

[0001-import-Add-importer-for-MELPA-packages.patch (text/x-diff, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Christopher Baines <mail <at> cbaines.net>
To: Carlo Zancanaro <carlo <at> zancanaro.id.au>
Cc: 38769-done <at> debbugs.gnu.org
Subject: Re: [bug#38769] [PATCH] import: Add importer for MELPA packages.
Date: Fri, 18 Dec 2020 12:40:26 +0000

[Message part 6 (text/plain, inline)]

Carlo Zancanaro <carlo <at> zancanaro.id.au> writes:

> Hi Chris!
>
> On Fri, Dec 18 2020, Christopher Baines wrote:
>> Looking at the code, elpa-package->sexp is a little awkward, the
>> code would probably be clearer if the (or ...) bits in the
>> package sexp were moved out in to functions that deal with
>> generating that part of the package.
>
> I agree with you. The "quasiquote, unquote, quasiquote, unquote" is a
> bit awkward, but I don't think it's unreasonable. I'm not that
> interested in revising the patch right now, but feel free to extract
> that logic before merging if you think it's necessary.
>
>> It seems to work though, so I'm happy to push this. Is this patch
>> still relevant?
>
> Yep, as far as I know this is still relevant.

Cool, I've gone ahead and pushed this as
b129b43475442b1da43d8209914fee215f98aa29. Hopefully it'll be helpful.

Thanks,

Chris

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.