+14  A: 

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.

Kyle Cronin
If I could, +1 again for best screenplay.
JasonFruit
Nice, yes; but practical? Would you only expect this for mode-settings? Or for any command? Should w3m-browse-url ALSO alert you to install w3m? In which case, the pm has to be aware of all possible interactive functions in all available packages, or be able to interactive browse on an unknown func.
Michael Paulukonis
That example is a "give" since the package name-space is prefixed, but not all packages play nice like that.
Michael Paulukonis
Google "php-mode" solves it.
J.F. Sebastian
try doing that programatically with a given function, say 'php-complete-function. nothing in the first page of results. doing 'emacs php-complete-function' and php-mode.el is the fourth result. But this is well formatted function with a pseudo-namespace, and a good pm could offer some suggestions.
Michael Paulukonis
I think the dialog should read: php-mode available from ftp.gnu.org. install? (y/n/v=view source)
tarsius
After reading that answer, I wish I could 'favourite' answers. :)
slomojo
+6  A: 

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.

A. Rex
If you had a package manager that held all your necessary packages, you could get this by simply writing elisp that auto-installs your packages by name and optional version. I don't think the package manager would need to do anything special.
Ryan McGeary
Uh, can the package manager at least dump my packages? I don't want to write any elisp like "(pkg-install this) (pkg-install that)" when the package manager **knows** what I have installed. Yes, the package manager wouldn't need anything special: just the ability to dump/read back what's installed.
A. Rex
Gotcha, understood. I guess I assumed that would be implied by a package manager. I haven't seen a package manager that couldn't list the installed packages.
Ryan McGeary
+13  A: 

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 makes it easy to publish Ruby Gems, 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.

Ryan McGeary
I love you :-) While I have voted the other comment so far up too; what you are suggesting is very much in the line of what I am working on. I will use git, I will use github, I want automatically adding (so I don't have to do it manually. However I think there is room for more than one pm.
tarsius
If what you put together fits the bill, I'd be glad to write a blog post about it on http://emacsblog.org I'd love to see a good, standard emacs package manager. I think it would help the community a ton.
Ryan McGeary
Take a look at magit.el and gist.el
J.F. Sebastian
I'd just like to add that PluginsKit does exactly this: http://github.com/Guille/PluginsKitIt is used by the MooTools project. http://mootools.net/forge/
henrikh
@henrikh: I don't understand what PluginKit does - what does "Plugins repository for open source projects linked to GitHub" mean?
tarsius
+8  A: 

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.

ShreevatsaR
+2  A: 

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

Alex Ott
+3  A: 

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

Guillaume Marceau
+3  A: 

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....

James Brooks
+5  A: 

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.

technomancy
+3  A: 

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.

Stephen Eilert
+1  A: 

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.

Charles Stewart
Putting a library in site-lisp is easy provided the library can actually be found :)
tarsius
@tarsius: is this ever a problem?
Charles Stewart
Yes, and I would know. While I was able to collect 1000 libraries several hundreds had to be put on the "can not find" list. By the way I do extract metadata including lists of dependencies. So even if you do not care about a central repository, the mirror will still add some value for you - I hope.
tarsius
Even spackages with so-called *simple* dependencies can cause problems, if the dependencies are invisible and untracked. Here's a fairly simple dependency: csharp-mode depends on a particular version of cc-mode with a particular fix. Yet, this dependency is not formally tracked; it is noted only in wiki articles and blog posts. Many people install the csharp-mode but not the required version of cc-mode, and all experience the same avoidable bug.
Cheeso
@Cheeso: Good example. There is a kind of versioning in GNU Emacs, through the version line convention for .el headers of packages: I guess this could be used here.
Charles Stewart
+2  A: 

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.

rejeep
Yes, the Emacsmirror - that's what I am currently working on :-) And for now I will concentrate on that, not actually a package manager. But I do generate metadata that can be used by a package manager. For example (:summary "Maintain a mirror of Emacs Lisp packages" :created "20081202" :updated "20091206" :license "GPL-3" :authors (("Jonas Bernoulli" . "[email protected]")) :maintainer ("Jonas Bernoulli" . "[email protected]") :provided (elm) :required ((("elx" elx) ("emacs" cl))) :keywords ("libraries") :homepage "https://github.com/tarsius/elm")
tarsius
As far as I know gems have to be written by the author of a package. For emacs http://tromey.com/elpa/ does something similar. But it does not have many packages. Mostly because elispers are lazy and don't bother writing the required package description and commit them to elpa. Also many old but still potentially useful packages exist, where the author can't really be bothered to write the pkg description. So my approach is to generate the data automatically from the library itself. But many authors do not even bother to follow the header conventions, so a lot of work still has to go into
tarsius
dealing with messed up headers, but I start to get somewhere. It is my hope that once the Emacsmirror takes of people will see the benefit it following the header conventions and using a modern vc. And especially stop dumping files like foo-mode-mypersonalversion.el on the emacswiki without describing the changes or ever merging in upstream changes.
tarsius
You are right about that people are lazy with their Emacs-scripts. However, following the approach I suggest above could still work. Some packages, will by the maintainer, be up to date. However, there are many Emacs-scripts out there that someone did but no longer care about. This could be solved by assigning each of those projects with a "Gem-maintainer".
rejeep
So if someone finds a package that no one longer maintains, that person should be able to just add it to the central location and be the new maintainer of it. This approach would hopefully keep the packages more up to date. And in this case I think that the source should be in a central location such as Emacsmirror. Because then people could fork the project, make improvements and make a pull request. Then the maintainer could just merge the changes. I think this would probably be a better approach then the header parsing.
rejeep
+1  A: 

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.

Cheeso
The question is still relevant: (1) the Emacs maintainers are willing to include package.el in 24 or so and (2) I have started with a mirror of package: http://www.emacsmirror.org.
tarsius