I recently refactored my Emacs config[1] to use el-get[2], which lets you install from the official package list from random git repos, and even from the emacs wiki if you're so inclined. My config is quite a bit simpler and easier to back on than it was before.
I had el-get installing stuff from emacs wiki until someone pointed out that it's completely insecure. Anyone who edits the wiki can inject arbitrary commands on your machine.
The only safe way to use emacs wiki code is to audit it first, and el-get can't do that for you.
There are various insecurities in the existing package ecosphere; e.g., provided a package X does not currently exist on Marmalade, anyone can upload a possibly-doctored version of X and make it available for installation. There's often no way to involve the upstream author directly, because many of them don't use or care about ELPA, and many are simply unresponsive.
A robust process for auditing packages is going to be hard to establish. In practice most developers seem to be happy to install any and all updates as long as they're reasonably sure they came from the original author. By using verified upstream source repositories both el-get and MELPA ensure this is the case, as long as one steers clear of libraries originating from the EmacsWiki.
Of course this is true. But it's also true of everything. APT, YUM, GEM, PYPI, anything where there is contributed code and you can't take legal action against someone.
Managed repositories are actually quite a bit different, since the requirements to edit emacs-wiki are quite a bit less stringent than those to submit a modification of someone else's package to a repository.
Apt, Yum, etc., require trust in the repository infrastructure and those select few with write access to a given repository. Emacs Wiki requires trust in the entire internet.
But we're not talking about that, as I said elsewhere, MELPA can have quite strict requirements (only the people allowed to commit to the github project of a repo can make a change, seems fair enough) and marmalade is aiming towards digital signatures. This would make marmalade the same as any other repository with low code review. How much do Debian people code review before a package goes into APT? or CentOS people?
Again, that's why we want to add signatures to packages. This is probably always going to be a two tier system though (some people are likely to not add a signature). There are other possible security systems as well, like MELPA could use github and say "yes, this package is authorative from there".
el-get is really for picking up the loose ends that don't make it into packages. Most Emacs users should start out with package and only move to el-get if they really need it.
Automatic package management is great. Now I just have to sit down and convert all the (quite numerous) extensions I've installed to using the package manager though :P.
This should help with keeping everything updated and going from computer to computer. My current system just has everything in a private git repository, but this isn't really ideal.
I should also probably submit the one major mode I've written. However, it's specific to a particular course taught by one professor, so nobody is going to be needing it for at least one semester :).
The way people typically do this is by VCing their configurations in a "dotfiles" repository. New machine? Pull your dotfiles, and create the symlinks in your homedir.
I currently do this with my entire .emacs.d directory, but it sounds like Derbasti only pulls his .emacs, and then has code to check for installed packages and get any that are missing.
Then everytime you installed a package it would get written into the list and everytime you moved your init it would all happen automatically.
That would be cool. And not hard to do either. You could just keep a customization variable of the "base packages" or something and have it saved by the standard custom stuff.
My init file is now much much simpler. It's easier to use customization once you're using packages. Package quality is also better than the old "install this file in your load-path somewhere" because there are established ways of doing stuff that work automatically (autoload cookies for example, I'll do another post on them sometime).
Very interesting but I was expecting something else when I read the title. I was hoping there will be packages that are useful for programers.
For instance, I'd love to see a good C# package. I tried to install a emacs-lisp script manually (csharp-mode-0.8.5.el) but failed since I am a total emacs rookie.
MELPA co-maintainer here. MELPA builds packages from source, so once there's a recipe, there's no need for package developers to prepare or upload new package files -- the packages just appear automatically on MELPA soon after the source code is updated.
I've often wondered the same. You basically end up having to have all three in your init.el file, since there doesn't appear to be a good rhyme or reason are to which packages are contained in which repositories.
As I've said elsewhere, we will sort this out in the end. Right now MELPA tends to be the latest and greatest and marmalade is more stable (read 'less exciting') releases. It would be good to have this recognized per-package though so hopefully we will merge the strategies of both repositories into a single repository that can do any one of those things for any package configuration.
The guys who run MELPA and me (I run marmalade) are talking and we hope that there can be just one repo in the end. It may take us a while to combine the best parts of the 2 systems in the right way.
[1]: https://github.com/peterkeen/dotfiles [2]: https://github.com/dimitri/el-get