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

Automatic publishing from version control

I'd love to see a standard, central, and single Emacs package manager. Right now, I'd put my money on ELPA, but there is still a long way to go.

The biggest thing that would help an Emacs package manager would be to make it super trivial to publish packages. In my opinion, I'd like to see this happen in combination with a version control system like git on a central hosted platform like GitHub -- something that would make it easy for authors to publish their packages and would make it easy for others to contribute back.

Similar to how GitHub (used to) make it easy to publish RubyGems, I'd like to see something similar in an Emacs package manager. For example, tag your repository with "vX.Y.Z" and have your elisp goodness automatically available to all.

The added benefit of using a popular backend like GitHub is that you'd immediately get a lot of exposure which should help drive its success.

Answer 2

I once spent some time writing a small package manager for Emacs.

http://gmarceau.qc.ca/plugin.el

I wrote:

Plugin is my attempt at creating a package manager for Emacs. Plugin will automatically downloads Emacs extensions, unpacks them in a directory, adds that directory to the load-path, generates auto-load annotations, and modify your dot-emacs file. The auto-load annotations are a little-known feature of Emacs. Once they are generated, Emacs extensions load quickly and incrementally, which is really nice if you have as many extensions installed as I do.

You will need two library files to get it to run, loop-constructs.el and record.el

Answer 3

I think the hackers for the iPhone got quite close to what I want, as does Ubuntu's "apt".

I like to be able to:

• add
• remove (package only)
• remove user settings
• view documentation
• upgrade ( after reading the change log)
• add new archive ( aka add repository )
• see dependencies
• see version
• search for name, keyword
• browse by (date added, date modified, name)
• save all installed packages & settings
• load set of packages & settings

I would like a main set of things that all work nicely and are the recommended way of doing whatever. Then a global set where everything working gets in. Then the ability for anyone to host their own archive.

It would be nice if this was all tied into git/svn/whatever so that you could install old versions. Make your own patches by forking off etc etc etc....

Answer 4

Easy configuration synchronization: I, like many people, use Emacs on many different computers and servers, some of them my own and some not. It would be amazing if the package manager had some sort of file which I could transfer from one computer to another; then, on the latter computer, the package manager would bring my Emacs into the state I like it in -- all the packages installed and configurations set. Combined with the ability to be able to easily install either site-wide (if one has root permissions) or as a single user, I could synchronize all of Emacsen everywhere.

Answer 5

I think that the package manager should take a lot of inspiration from Rubygems. I also think that it should have a site like Gemcutter.

A central repository could also be nice (like Emacsmirror). This however may not be necessary if a site like Gemcutter exists that collects all packages.

I think these things are important for this to work.

• Central location of some kind that collects all packages
• Easy to add packages
• Easy to maintain packages
• Easy to contribute to other packages
• Easy to install, uninstall and update packages
• Possibility to add package dependencies
• Common structure for all packages

So a package manager like Rubygems with a site like Gemcutter and a central repository like Emacsmirror (preferably on Github because of it's social coding) would do Emacs really good.

All in all I think that much inspiration should be taken from Rails and how Rails handles Gems.

Answer 6

Package managers don't offer anything I value w.r.t. single-file elisp packages with simple dependencies: adding and deleting from site-lisp has never caused problems. It's packages that depend on external programs (e.g., ispell), multi-file packages (e.g., auctex, org-mode) that can be tricky. Can't think of any single-file elisp package with nontrivial dependencies, offhand.

For these, short of a package manager, I'd like emacs' elisp-packages to acquire test suites which can be run en masse, and which provide useful information in the event of dependency failures.