package.el is slick stuff. Those guys convinced me to make some of my packages ELPA-compatible when it was first starting out. It's super easy to use as a user, super easy to use as a developer, and makes it really nice to install and use dependencies for extensions.
It's totally awesome that it's in the main codebase now.
Now we just need to make a tool for automating the release process. I'm imagining a minor-mode that integrates with vc to take a given tag/branch/what-have-you and upload it to Marmalade.
The idea is sound and it seemed slick when I tried to use it. Unfortunately, I got several errors when trying to install packages like Slime, Paredit and Clojure-mode. I've since manually setup those packages for myself and they work fine, so I wonder what the problem was that I encountered.
I had an enormous amount of trouble setting that stuff up, partly because I also wanted to use Common Lisp. I also was unable to uninstall any package.
Everything about package.el and ELPA has always given me the feeling that it's a bit rough. My hope is that Emacs 24 will straighten it all out.
Last time I looked at this, they punted on interoperability with the system package manager. Are they likely to ever care about this, or is it just for people who aren't appalled at the thought of polluting individual machines with random libraries whose interdependencies are invisible in the dpkg or rpm database?
It's like this for anywhere where you don't need to compile anything. Perl is an example; Debian depends on Perl internally, so you really don't want to depend on it as a programmer because it's going to change according to Debian's needs. If you fuck up @INC by installing stuff in there, then you run the risk of breaking your operating system. So most Perl programmers on Debian use some combination of local::lib or perlbrew and just have a Perl-install-per-app.
Emacs is a little different in that nothing is going to break the system; but if user A wants Emacs extension A and user B wants Emacs extension B, but they conflict (say, by depending on different versions of foo.el), then the system can't resolve that. By delegating the management of third-party extensions to the user, this conflict is avoided.
My personal policy is that I only use OS packages for things I don't care about. I mostly use emacs, conkeror, rxvt-unicode and xmonad, so all those packages are intalled from git/darcs into my homedir so that I can easily hack on them. Stuff like "ls" I let the OS handle, because the stock "ls"'s featureset meets my needs.
Anyway, package systems are nice from an organization perspective, and there's no reason not to submit your favorite Emacs extensions to Debian. But it's not a perfect answer to every situation.
I agree. I think we need a protocol which is both package manager (dpkg, rpm) and environment (emacs, python, ruby) agnostic, with plugins to handle the specific cases.
I think the starting point should be an RVM/perlbrew-alike for each environment; that'll keep the environment developers and those who like to be on the bleeding-edge happy. Then plugins to handle {gem,elpa,pip,...} -> (sufficiently general intermediate format) -> {deb,rpm,msi,...}, and we're done.
It's totally awesome that it's in the main codebase now.