[PATCH] import: Add importer for MELPA packages.

  • Done
  • quality assurance status badge
Details
3 participants
  • Brett Gilio
  • Carlo Zancanaro
  • Christopher Baines
Owner
unassigned
Submitted by
Carlo Zancanaro
Severity
normal
C
C
Carlo Zancanaro wrote on 28 Dec 2019 02:59
(address . guix-patches@gnu.org)
87v9q1jjlf.fsf@zancanaro.id.au
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
Attachment: 0001-import-Add-importer-for-MELPA-packages.patch
B
B
Brett Gilio wrote on 7 Jan 2020 20:39
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 38769@debbugs.gnu.org)
87r20bqco9.fsf@gnu.org
Carlo Zancanaro <carlo@zancanaro.id.au> writes:

Toggle quote (26 lines)
> 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]
<brettg@gnu.org> <brettg@posteo.net>
C
C
Carlo Zancanaro wrote on 18 Mar 2020 03:54
(name . Brett Gilio)(address . brettg@gnu.org)(address . 38769@debbugs.gnu.org)
874kum9xtv.fsf@zancanaro.id.au
Hey Brett!

It's been a while, but I've finally found time to revisit this
patch.

On Wed, Jan 08 2020, Brett Gilio wrote:
Toggle quote (5 lines)
> ... 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.

I've done this.

Carlo
Attachment: 0001-import-elpa-Fetch-MELPA-packages-with-a-stable-git-r.patch
C
C
Carlo Zancanaro wrote on 30 May 2020 16:26
(address . 38769@debbugs.gnu.org)
87367hxzwh.fsf@zancanaro.id.au
I just saw a message on guix-patches that reminded me that this was
still sitting around. Can anyone help me out getting this change into
Guix so Emacs packages are easier to import correctly?
B
B
Brett Gilio wrote on 25 Jul 2020 03:49
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 38769@debbugs.gnu.org)
87mu3o4b4g.fsf@gnu.org
Carlo Zancanaro <carlo@zancanaro.id.au> writes:

Toggle quote (4 lines)
> I just saw a message on guix-patches that reminded me that this was
> still sitting around. Can anyone help me out getting this change into
> Guix so Emacs packages are easier to import correctly?

Hey Carlo,

Sorry nobody got back to you on this! I am just recently coming off of a
haitus from contributing. I have a few things still on my backlog, but I
have marked this bug for review ASAP! If somebody else can get to it
faster than me, great! If not, I will surely look it over soon!

Brett Gilio
C
C
Christopher Baines wrote on 18 Dec 2020 11:32
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)
87a6ub2ymu.fsf@cbaines.net
Carlo Zancanaro <carlo@zancanaro.id.au> writes:

Toggle quote (13 lines)
> Hey Brett!
>
> It's been a while, but I've finally found time to revisit this
> patch.
>
> On Wed, Jan 08 2020, Brett Gilio wrote:
>> ... 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.
>
> I've done this.

I've had a go at trying this out, I tried importing ack from elpa and a
from melpa, and it seemed to work OK. The packages built at least, and
the outputs look reasonable.

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.

It seems to work though, so I'm happy to push this. Is this patch still
relevant?
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl/chSlfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdPiA//fHvV/A3MrQYIUuoQFee4vT6RfocLTcrV
rW3wxSDHQ8JaEtOc5l4kWrTe8od4+j2Pe+Z/K5I52aRBu8SurbC34dnCIwhbIABv
WD551bSjE3G3eXiy1wGb9nAkLMl7KtDi5umEpCwq/SK+1lWOonKQM0I9bTNKwNUq
IG7yXYA9ou7utfdoAo2cqY5CRf1sIryjzfKoYYcdtYYTXQGSJwhNC0SbHW955nMu
YRWUgkTgdxcDIfCagDWKjkC7PyKq/SUeWmDK/VRzzgpecKdWHDjWfFLFVR+gmgpR
/WWOluZdzRhV0HRgfoxeq1odYv5s0eLx8ui/04YJJ588gZ+6+ZyiECcVJUy2abhy
bx9ysS1I/U3z45v8vX6D1m9K6HI5Cvmg2AE/XhtnoUoCK8Cb+HxSZRYaNJlfOo13
5swwmUw5cAZhvm0TBUS5q/OOeVcMhXjBgc5s/JaTZ3Bs2TrgRBDFMKAvcS6/49cw
Pz2B5EqOInX0JvOvQWRLOuARRDJxD4PS7Ymzq25xZrJ9J+C+fWQwcQ0zLQvaweBr
ybDJ6Hzlc2QAP1LBRV4cLdifPAEYVlbjUe0ntC6T9sYNca1ivU/nm0pcORLjg1xC
ReX0QUzUbxqoH2Sf4vsZtdCzN6X4iMKldC/fCCWWD2yFsdA6miraDQiFfnVmaAbi
+3VY51hRPNc=
=9SjF
-----END PGP SIGNATURE-----

C
C
Carlo Zancanaro wrote on 18 Dec 2020 12:16
(name . Christopher Baines)(address . mail@cbaines.net)(address . 38769@debbugs.gnu.org)
87zh2b2wle.fsf@zancanaro.id.au
Hi Chris!

On Fri, Dec 18 2020, Christopher Baines wrote:
Toggle quote (5 lines)
> 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.

Toggle quote (3 lines)
> 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.

Carlo
C
C
Christopher Baines wrote on 18 Dec 2020 13:40
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 38769-done@debbugs.gnu.org)
87sg831e4l.fsf@cbaines.net
Carlo Zancanaro <carlo@zancanaro.id.au> writes:

Toggle quote (18 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAl/cozpfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xf3iBAAuJFHvjtuqSDn7TzonW9sAnWpKXlnmX9L
KDTM9/SSx3uVN7RG++sPBVFV9OH7zajMg+v1bIzdndysWtTKhkVphgyM1nxB2Gh7
E+IZ6uD2IvYYqdYtRHBboEzQaBnuYjF5Mfo9OT0leTfIIhAtGJuVlH7xg/348Xh3
vfxYHDdOYDUf4Ee93ABqxMtFkzWsI/NpwZ+7+7/Oas5Jkt4tVXq+ZcFsw+SpLay1
kfu89Lns6/9Pf+Z8dRVX8Ry0WcAfKq4hZ44ROF3XvPkC0MMfcPZf0J2OPXozSVZK
iBSREpS+OT8i2Yp4C5DRPFAt+q7oStHsw2Ke+zj6trpGGLos0OakxBP6+S5MeqyU
dLlcpl5aHOwiFnxfKocNhF+HY70Sxdh2dJQQ2R7sbRscfAb5I2nXHsuvTdq53jAj
2+D6NPO0aGQmw3A57EjSgxkX3hdcwsti8PAye+VLW8eyDBNB6tF+yLOjceTAcF7V
gfp6JnAkx5gI0Sq6PU/D+cuXCnmbWGJGwziANOsJHo2C5Wf/DusZy7NUpbS07jAJ
Vvi7ow0erkGZ5aqnp9F255ZLORlBa9F7m2gHd3EQmLhQ+4L+ADZlvfS4UQ+cMYUT
NiZNEE+tyf+LbZK6dKqwyt+VGQc/CuuMr76CdWS74aYy5rMyMTaPmdc95XT1ehiD
SwmMgdZ+M2g=
=l+Cg
-----END PGP SIGNATURE-----

Closed
?