What do you expect from a package manager for Emac

Question

Although several thousand Emacs Lisp libraries exist, GNU Emacs, until version 24.1 did not have an (internal) package manager.

I guess that most users would agree that it is currently rather inconvenient to find, install and especially keep up-to-date Emacs Lisp libraries.

Pages that make life a bit easier

For versions of Emacs older than 24.1:

• Emacs Lisp List - Problem: I see dead people (links).
• Emacswiki - Problem: May contain traces of nuts (malicious code).
• Emacsmirror - The package repository I am working on. Problem: No package manager supports it natively yet.

Some package managers

It's not that nobody has tried yet. (Some of these did not exist when this question was asked.)

• auto-install
• borg.el - Assimilate Emacs packages using Git submodules.
• el-get.el - Supports many sources.
• elinstall.el
• epackage aka DELPS - Debian packaging concepts applied to Emacs Lisp packages.
• epkg.el - This is now just a tool for browsing the Emacsmirror.
• install.el
• install-elisp.el
• jem-pkg.el
• package.el - ELPA. Seems like it will be included in Emacs 24.

---

UPDATE -- package.el is included in GNU Emacs, starting with version 24.1

---

• pases.el
• pelm - Command line installer; using php.
• plugin.el
• straight.el - Recent and experimental, has not reached 1.0 release yet.
• use-package.el
• XEmacs package manager

package has been included in the Emacs trunk. epkg is not ready yet and also currently not available. At least install-elisp, plugin and use-package do not seem to be actively maintained anymore.

I have created a git repository containing all these package managers as submodules.

Some utilities that might be useful

Package managers could use these utilities and/or they could be used to maintain a mirror of packages.

• date-calc.el - Date calculation and parsing routines.
• ell.el - Browse the Emacs Lisp List.
• elm.el, elx.el, xpkg.el - Used to maintain the Emacsmirror.
• genauto.el - Helps generate autoloads for your elisp packages.
• inversion.el - Require specific package versions.
• loadhist.el, lib-requires.el, elisp-depend.el - Commands to list Emacs Lisp library dependencies.
• project-root.el - Define a project root and take actions based upon it.
• strptime.el - Partial implementation of POSIX date and time parsing.
• wikirel.el - Visit relevant pages on the Emacs Wiki.

Discussions about the subject at hand

• emacs-devel 20080801
• comp.emacs 20021121
• RationalElispPackaging

The question (finally)

So - I would like to know from you what you consider important/unimportant/supplementary etc. in a package manager for Emacs.

Some ideas

1. Many packages (the Emacsmirror provides that largest available collection of packages, but there is no explicit support in any package manager yet).
2. Only packages that have been tested.
3. Support for more than one package archive (so people can choose between many/tested packages).
4. Dependency calculated based on required features only.
5. Dependencies take particular versions into account.
6. Only use versions that have been released upstream.
7. Use versions from version control systems if available.
8. Packages are categorized.
9. Packages can be uninstalled and updated not only installed.
10. Support creating fork of upstream version of packages.
11. Support publishing these forks.
12. Support choosing a fork.
13. After installation packages are activated.
14. Generate autoload files.
15. Integration with Emacswiki (see wikirel.el).
16. Users can tag, comment etc. packages and share that information.
17. Only FSF-assigned/GPL/FOSS software or don't care about license.
18. Package manager should be integrated be distributed with Emacs.
19. Support for easily contacting author.
20. Lots of metadata.
21. Suggest alternatives before installing a particular package.

I am hoping for these kinds of answers

• Pointers to more implementations, discussions etc.
• Lengthy descriptions of a set of features that make up your ideal package manager.
• Descriptions of one particular desired/undesired feature. Feel free to elaborate on my ideas from above.
• Surprise me.

Answer 1

What I expect most is that everything useful is on it, and works well. This requires you (or a team of maintainers) to aggressively pursue packaging everything for it, and doing whatever that involves — emailing every author of a useful package, and so on.

For instance, the reason Debian (and its derivatives: Ubuntu etc.) is so good is that you can happily use your system without ever having to install something outside the repositories, and that everything on it is thoroughly tested. The actual features of the package manager are important, but secondary to the managed packages themselves.

Answer 2

I'm nearly positive that the best solution involves submitting more packages to ELPA and adding multi-source support to package.el. The Emacs maintainers have said that they would consider including package.el in version 24 as long as it pointed to an FSF repository by default.

Of course, submission also needs to be an automated process too; the current method of mailing the ELPA maintainer only works on a small scale.

Answer 3

Besides the mentioned above, i expect something like debian, and other repositories - set of the stable, experemental, untested packages. Ability to add my own repositories - i use lot of the packages directly from VCS, so it could be useful to create my own packages

Answer 4

I don't know how fresh this question is...
but the model I would like to see is CPAN. I also don't know Rubygems but it sounds similar to CPAN.

CPAN is a perl archive + library management system. When I need to write a perl program that requires... FTP or SOAP or JSON or XML or ZIP, or...etc, I can run the CPAN package manager, select the requisite package for download, view and verify the dependencies, then install everything. CPAN is mirrored .."everywhere".

CPAN works wonderfully for my purposes, and something similar for emacs would be nice to have. It also supports building C/C++ code on demand.

That's what I would like to see in emacs.

Some further comment on requirements.

• explicit download of packages. No auto install. No invisible downloads. I want to ask for new libraries or new function.
• I should be able to list the name/version/timestamp of installed packages.
• If my friend gives me his list, I should be able to diff his emacs state against mine.
• check-for-updates function. What updates are available? What do they fix?
• depedency checking, verification, and download. If I install csharp-mode and it requires v5.0.28 of cc-mode, then it should confirm with me, that I must also download cc-mode.
• there should be some sort of community ranking of these packages, like ranking torrents on isohunt. I want to see if a package has 3 upvotes or 3000.
• "transactional" behavior. If an install goes boom, it must unwind to a last-known-good state.
• failsafes. If I've put custom mods in linum.el, it should refuse to install a new version over my changes, unless I explicitly allow it. It should warn me before even starting. Do this with checksums/md5's over the existing install.
• have the option of running some packages from compressed archives, like zip files. So I never have any doubt that I have not updated any of the embbedded elisp.
• ability to use mirrored hosts for package distribution.
• all this function should be accessible through M-x library-manageemnt or something.

Finally, it would be nice to have a way to segregate or organize libraries of functions. Hierarchical namespaces. Emacs' flat namespace is very dated. This is sort of independent but complementary to the core function of package management. I'm not a lisp guru so I don't know how hard this would be; maybe there is already a way to do it.

Answer 5

No matter how this is done, the most important thing in my opinion is that it should be trivial to submit packages to the repository. At the same time, we do not want those packages to be instantly available, to guard against malicious code(and due to licensing issues). Unless there is a "trust" system in place, based on crypto signatures.

Also useful:

• "metapackages", to install several packages at once.
• In the same way, we should be able to install a set of elisp files, for maintainability
• "Broken" packages should not be allowed to disrupt Emacs startup. This is easy and I have it implemented in my own .emacs
• Ability to install files other than scripts. This is often overlooked, but very useful. You'd be able to, for instance, ship images, for icons, toolbars, etc.
• Versioning:package X requires package Y > 1.0
• Testing: perform basic sanity checks, testing for conflicts (keybindings, function redefinitions, functions that are expected to be present but aren't, etc).
• BUG TRACKING: I can't stress the importance of this enough. Having a centralized place to report package bugs (and being able to track them) is extremely important to assure the quality of the packages.

Some sort of compressed archive seems to be best to do some of the above.

---

So far, a much improved ELPA seems the way to go.

Answer 6

I'm still learning Emacs, so I haven't had a chance to look into package managers, but a great feature would be to inform the user that the package is available if they try to use it but it's not on their system. For example, I wanted to edit a PHP file on a server once, and I tried

M-x php-mode

and Emacs was all like

M-x php-mode [no match]

when it should have been like

php-mode available from ftp.gnu.org. install? (y/n)

and then it would have installed and loaded up php-mode for me. That would have made my day right there.