bug#38769: closed ([PATCH] import: Add importer for MELPA packages.)

[GNU bug Tracking System]

Your message dated Fri, 18 Dec 2020 12:40:26 +0000
with message-id <87sg831e4l.fsf@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@gnu.org.)


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

--- Begin Message --- Subject: [PATCH] import: Add importer for MELPA packages. Date: Sat, 28 Dec 2019 12:59:40 +1100 User-agent: mu4e 1.2.0; emacs 26.3

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
Description: Text Data

--- End Message ---

--- Begin Message --- Subject: Re: [bug#38769] [PATCH] import: Add importer for MELPA packages. Date: Fri, 18 Dec 2020 12:40:26 +0000 User-agent: mu4e 1.4.13; emacs 27.1

Carlo Zancanaro <carlo@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
Description: PGP signature

--- End Message ---