Pros and cons of contributing to elpa, nongnu elpa, or melpa

When you make a new emacs package, how do you decide which package archive to submit it to?

MELPA is the easiest to get into. You just open a PR, apply the fixes/suggestions, and done. ELPA is the hardest. Your package needs to only have GPL compatible dependencies. And IIRC there's some actual paperwork involved for copyright? Or was that just for core libraries? I guess nongnu is like ELPA but without the GPL restriction? ELPA and nongnu are enabled by default in Emacs, so it has the least friction for users. I personally prefer packages from these two, and only use the one in MELPA if it isn't available anywhere else. Plus, I believe there is _some_ level of review/auditing involved when submitting new versions of packages in ELPA/nongnu. For MELPA, after the initial submission, future versions are not audited at all.

If you do the paperwork for ELPA, the effort required to submit for it are the same as the others, I think ELPA/nongnu has higher review standards than MELPA. There is also code ideological differences between ELPA/nongnu and MELPA. The one might require things that the other require to avoid

GNU ELPA requires copyright assignment (the paperwork), as packages in it are considered part of Emacs. Adding packages to GNU ELPA has the same requirement as adding code to Emacs itself. AFAIK the restriction on dependencies is stronger than just GPL-compatible: any dependency must also be part of Emacs (or part of GNU ELPA) (Edit: [or NonGNU ELPA](https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00847.html). Sorry!). NonGNU ELPA requires packages be GPLv3-compatible (and their documentation to be GNU FDL v1.4-compatible), see [its README](https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org). I don't imagine you'd be able to depend on something that isn't on NonGNU or GNU ELPA either. If a package submitted to MELPA depends on a package that's on NonGNU but not MELPA I'd expect the author will have to discuss with MELPA maintainers about it, but I'm not sure if this has ever happened yet. (BTW, while "ELPA" is sometimes used to refer to GNU ELPA, it's more accurate to use its original meaning, "Emacs Lisp package archive", and call GNU ELPA by its full name)

With straight.el it's quite painless to pull from a git repo directly, so I wouldn't bother publishing a package to the mentioned repos, until you have enough users and went thru a few iterations of your code. I think we should keep ELPA/MELPA for the more proven/mature packages, so they serve as a good way to discover packages, for a long time coming. otherwise these package sources will accrete a lot of obsolete software. of course, it will just delay the inevitable, but that gives us more time to figure out how to deal with this issue. pulling from disparate git repos directly has its own challenges, but at least it provides namespacing, which is a pretty good way of avoiding naming conflicts. npmjs.com is an example, which i think shouldn't be followed. nixpkgs is an other example of how a central package repo can balloon to unmanageable sizes. they came up with the flake concept, which mitigates that issue, amongst other problems. centralized software repos are a good solution to kickstart some language ecosystem of course, because of their simplicity; I'm not arguing that.

> For MELPA, after the initial submission, future versions are **not audited at all**. Yup. And this is often overlooked, I expect. (And even that initial "audit" amounts to what, exactly? Who knows? Is it more than just a check that you've provided the necessary metadata - autoloads etc.?) Just because some code is from a GIT repository is no assurance that it's benign. Users would do well to at least eyeball whatever Lisp code they download - from anywhere.

I no longer put anything into the package repos. It's much easier to install from Git these days, and I dislike even the relatively low barrier that MELPA has.

When ready, adding your code to a major package archive will increase its discoverability.

i'm not sure the extent to which any of my packages would have got any users in the first place if they weren't on MELPA.

Overlooked? I hope not. This is a industry problem or how does this differ from any other package repo? Like npm, pypi or crates? What's a Solution? Would it be something like quicklisp which is heavily curated but afaik there is ultralisp which is much fast turning and probably has the same problem. Some kind of web of trust would be good ;)

>Adding packages to GNU ELPA has the same requirement as adding code to Emacs itself. I find this misleading, if not incorrect. It is incredibly easy to get a package into GNU ELPA. >any dependency must also be part of Emacs (or part of GNU ELPA). Incorrect. A package in GNU ELPA can depend on a package in NonGNU ELPA.

>I wouldn't bother publishing a package to the mentioned repos That's a good way of getting me not to check out your package. If that's desirable or not, well...

Most users use package.el and don't "install from git", so that will get your package(s) much less attention and users.

Fortunately for me, it's not a competition for attention or users, so I don't care one bit.

yeah, that's what I was trying to say. OP, would you want Stefan spending his time on checking out your new package or keep focusing on core Emacs development? With publishing to ELPA/MELPA, your "new package" might reach way more people, than you can handle feedback from... EDIT: Just to be perfectly clear, to me "new package" implies, possibly immature code, with only the package author being the sole user of it.

"Adding packages to GNU ELPA has the same requirements as adding code to Emacs itself" doesn't assert whether it's easy or hard. Both require copyright assignment. If copyright assignment is easy for you, adding code to Emacs is likely as easy as adding packages to GNU ELPA. --- Do you know of a document or perhaps email thread that actually explains what GNU ELPA packages are allowed to depend on? My assumption came from how they are considered "part of Emacs" and I assumed it's the same standard. GNU ELPA's Readme doesn't seem to explain it.

>Do you know of a document or perhaps email thread that actually explains what GNU ELPA packages are allowed to depend on? https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00847.html

>(And even that initial "audit" amounts to what, exactly? Who knows? Is it more than just a check that you've provided the necessary metadata - autoloads etc.?) In my experience, it is (at least sometimes) way more, my code was rather thoroughly read and several changes were suggested/requested.

if you still want to use *ELPAs - quelpa is a way to go, since it's compatible with package.el

Am I the person who you wanted to answer? I think an initial audit is a good thing but there should be some kind of chain of trust in place. Signed commits, commits/releases from specific users or something like that. But there we are again at my point from before (ultralisp), it has to be fast & easy to be used.

Thank you!