[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding advisory notification for non-ELPA package.el downloads

From: Joost Kremers
Subject: Re: Adding advisory notification for non-ELPA package.el downloads
Date: Mon, 10 Jul 2017 22:43:12 +0200
User-agent: mu4e 0.9.19; emacs

On Sat, Jul 08 2017, Clément Pit-Claudel wrote:
On 2017-07-07 21:59, John Wiegley wrote:
I have a feeling that a lot of package authors choose MELPA because the barrier to entry is so low, and they may not realize how easy it
is to get it into Emacs as well.

It's not that they doesn't realize how easy it is: it's that it's not easy.

Getting into MELPA requires a writing a one-line Lisp form and submitting it for inclusion. Getting into ELPA requires subtle git invocations that end up mashing up the history of your project with that of tens of others, while fearing to break the entire ELPA repo because of a missing copyright line in a test file.

And ELPA makes maintaining the package more painful, too: picking out the commits made by others and copying them on your personal repo requires further arcane git invocations — same for importing new commits from your personal repo. And of course you lose other MELPA goodies, like getting download statistics.

For now, the main motivation to publish on ELPA is ideological — not practical. My feeling is that package authors chose not to publish on ELPA because they get all they need from MELPA, for a fraction of the invested time.

Let me just say 'hear, hear' to that, as one of those typical package maintainers. I thought about using ELPA instead of MELPA a few times, but reading such comments as "arcane git commands", "mashing up your history" and "breaking the entire ELPA repo", my immediate reaction is "oh well, some other time, perhaps". I should probably point out that my git skill level is low, and while I'd be willing to learn more, the time investment if often prohibitive. (I'm not a professional programmer, just a guy with a hobby.) With MELPA, that's sufficient, though, and Github has a lot of help pages that provide clear and concise instructions for things I don't do every day, such as dealing with PRs or keeping a fork up-to-date with its upstream repo.

I've just been skimming the GNU ELPA README on http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README and although it *looks* like once thing's are set up, I shouldn't have to do much more than a git push to update my package, the process of getting there seems quite involved.

More importantly perhaps, the entire workflow seems to be different. With MELPA, I put my code in a publicly accessible repo that I create myself, on a service of my own choosing (in my case Github), and then tell MELPA where to look for it. With GNU ELPA, it seems I need to put my code somewhere specific, and it's not in a repo that I create or own.

In itself, it's not a big problem that GNU ELPA uses a different workflow from MELPA, but, speaking for myself, it would be good if the ELPA README (or some other document) would contain a few paragraphs explaining the differences and would cover the steps involved in such a way that they make sense for someone with a less-than-stellar understanding of git.

Anyway, just my two €0.02.

Joost Kremers
Life has its moments

reply via email to

[Prev in Thread] Current Thread [Next in Thread]