Back to the schedule
Previous: How Emacs made me appreciate software freedom
Next: Manual Package Management in The Era of Repositories - Why and How

NonGNU ELPA Update

Philip Kaludercic

Q&A: live Q&A or IRC
Duration: 6:28

This talk was also streamed at an alternate time for APAC hours: https://libreau.org/past.html#emacsconf21

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Description

NonGNU ELPA was announced last year, as a package repository that will be enabled by default in Emacs, but doesn't require any copyright assignment. This means that a lot of popular packages can now be installed easier, without any additional configuration.

In this talk I would like the give a reminder of what NonGNU ELPA is and how it works, update the participants on what has happened since last year and what maintainers have to do if they want their packages to be added to the repository.

Discussion:

• It was really pleasant to listen to.

Transcript

Hello! My name is Philip, and I'll be giving a brief update on NonGNU ELPA. Before we begin, let's first make sure everyone's on the same page. What is NonGNU ELPA? Put simply, NonGNU ELPA is a new Emacs Lisp package archive. similar to its sister archive, GNU ELPA. The main difference is that GNU ELPA regards each package in the archive to be part of Emacs itself. This means each significant contributor has to have signed their copyrights to the Free Software Foundation. NonGNU ELPA is made for packages that cannot ensure this condition.

[00:00:39.363] The immediate consequence of all of this is that more packages can be installed out of the box. All you need to install, for example, magit, evil-mode, slime, is a simple M-x package-install.

[00:00:52.723] The more subtle consequence is that ELPA distributes stable packages by default. This differs from, for example, the community-maintained package archive MELPA, where each change in the respective package repository triggers a new package to be rebuilt. Of course, "stable" here has to be taken with a grain of salt because, on the one hand, a package maintainer can be very careful to avoid buggy code in their default branch, and on the other hand, a package maintainer can be too eager to tag a new release without properly checking that the code works as intended. My personal hope is that more people using NonGNU ELPA be incentive for increase for package development to shift away from the currently predominant rolling release model, improving the overall stability of Emacs configurations.

[00:01:45.523] Another side effect of the initiative is a chance to clean up the Emacs package space. Over the last few years, a lot of packages have been abandoned, have been broken, duplicated, or even in some cases, replaced by functionality in Emacs itself. When reviewing packages for NonGNU ELPA, the opportunity to avoid these problems will hopefully also improve the general quality of Emacs packages.

[00:02:13.923] So, what is this update about? I'm taking Richard Stallman's announcement at EmacsConf 2020 as my reference point. There, the idea, the history, and the motivation was explained, and the call for contributions was made. I won't be going into these aspects again this year. As this implies, there was nothing concrete at that point.

[00:02:38.683] The first practical steps towards NonGNU ELPA were taken up by Stefan Monnier. This included updating GNU ELPA's build system to support the requirements of NonGNU ELPA as well. And so eventually, the idea became a Git repository, nongnu.git on savannah, then a website, elpa.nongnu.org, and then around late December of last year, NonGNU ELPA was also added to the package-archives list.

[00:03:08.643] Sadly, progress stalled from this point on, with the new archive consisting of only five or six packages. It took until August for more packages to be added, some by their respective authors, such as Magit and Projectile, but most by contributors such as myself. As of recording, the archive has around 70 packages, with more pending to be out soon. These include popular applications such as the previously-mentioned Magit, SLIME, or wgrep, major modes like php-mode, rust-mode, go-mode, clojure-mode, lua-mode, markdown-mode... You get my point. And a number of visual themes, among other things.

[00:03:49.443] If you are interested in using NonGNU ELPA, but you are still bound to an older version of Emacs, all you have to do is to add the snippet from the NonGNU ELPA home page updating the package-archives variable. For Emacs 28 and newer, one might have to watch out that you're not setting package-archives directly, and if you are doing so, to update the value. Emacs 28 only updates the default value and will not manipulate the user's configuration.

[00:04:17.043] Finally, a short note for package developers. Most packages up until now haven't been added by their maintainers. For the most part, I have been collecting and reviewing the packages which have been added, which takes time and is one of the main reasons why we're still at only 70 packages. This is of course not a permanent solution. The intention here is to bootstrap, so to say, the interest in NonGNU ELPA by making it more interesting to you and thus more interesting to contribute to.

[00:04:50.563] If you are interested in adding a package that already exists, or a new package to NonGNU ELPA, all you need to do is send an e-mail to the Emacs development mailing list, emacs-devel@gnu.org. This is an open mailing list and requires no special registration. Your message should mention NonGNU ELPA in the subject and contain a link to a public Git repository in the body. Ideally, a brief explanation on what your package does would be much appreciated. The proposal will be reviewed by the readers of the mailing list, and after a bit of back-and-forth on possible issues and improvements, the package will hopefully be added to NonGNU ELPA itself.

[00:05:34.443] The simplest mistake a lot of packages make is to either not have or maintain a version attribute in the package header. This is done despite actually being necessary for a well-formed Emacs package according to the Elisp manual. ELPA relies on this tag to detect new package versions that will be built and distributed. If the version isn't updated, no new package will be released, and any changes won't be made public. So, that's that on NonGNU ELPA.

[00:06:07.683] To summarize, NonGNU ELPA is an Emacs Lisp Package Archive for Emacs, without a need for copyright assignments. It works, it exists, and it's been used already. I'm looking forward to more packages being added to the archive and improving the overall experience of Emacs out of the box. Thank you for your interest, and goodbye. [captioned by sachac]

Back to the schedule
Previous: How Emacs made me appreciate software freedom
Next: Manual Package Management in The Era of Repositories - Why and How