+1. el-get is the homebrew of Emacs, and is even better for letting you hook in to do custom init.

I use package.el Any advantage to swapping to el-get?

Yes, package.el doesn't install arbitrary snippets from anywhere on the internet.

It takes about five minutes to take a library that isn't packaged and publish it on Marmalade, and then anyone can depend upon it.

el-get made lots of sense back in the day when package.el only supported tromey.com, but now that there's a community repository I don't see the point.

OK. My old complaints against package.el were as follows:

1. Packages need to be updated manually by maintainers. I can't use package.el to install the master branch of my favorite project on GitHub, or an old snippet on EmacsWiki.

2. Marmalade (the community repository) has licensing requirements for package inclusion.

Are those two assumptions incorrect?

> 1. Packages need to be updated manually by maintainers.

Yes, but considering uploading new versions can be done with M-x marmalade-upload-buffer, generally Marmalade encourages short release cycles. So there's not much reason to ever work from master unless you're hacking on it yourself, in which case you already have it checked out.

> 2. Marmalade (the community repository) has licensing requirements for package inclusion.

This is not specific to Marmalade since Emacs itself has licensing requirements. Every elisp library is a derivative work of Emacs itself, therefore it must be distributed under the same license.

EDIT: Perhaps you're thinking of elpa.gnu.org? That repository requires copyright assignment for libraries to be included, but Marmalade does not.

OK. I was wrong about licensing requirements.

I think you're slightly confused about el-get's purpose: it isn't to replace package.el. el-get supplements package.el and provides options for people who want to run the latest and greatest versions of libraries, or who can't be bothered to monitor the odd elisp snippet and update Marmalade every time it changes.

Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers.

Here is an example recipe for el-get. I haven't tried creating uploading anything to Marmalade yet, so I can't compare the ease of use.

https://github.com/dimitri/el-get/blob/master/recipes/evil.r...

One last note: You may find that el-get lowers the barrier for contributing to libraries. If you find the odd bug in a mode you use, the source code is always checked out in ~/.emacs.d/el-get and it would be practically criminal to not fix it. With package.el, you have to reinstall the library first.

> Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers.

That's my main objection. If you write an el-get recipe, it benefits el-get users. If you use package.el, all users (of Emacs 24+) benefit.

You made me laugh :)

You're right, of course, but only because the Emacs community chose an inferior solution to begin with. Let the better package manager win. Don't tell people not to use el-get because it is so convenient that they wont use package.el anymore.