Phil Hagelberg on Emacs new package manager. | Hacker News Reader

Phil Hagelberg on Emacs new package manager.

technomancy.us

83 pointspdelgallego14 comments

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.

</dream>

So what are you waiting for? Get to work! ;)

I'm working on one. I'll upload it once I have the chance to finish it up.

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.

This requires a bit more work but is also more flexible:

https://github.com/dimitri/el-get

It helps you manage emacs packages and elisp that are not packaged.

After hours customizing vim with pathogen and git submodules and recompiling a bunch of timed I really wish vim had something like this

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?

This sort of "integration" is enormously difficult. In fact, it's even ill-defined.

I challenge you to design a useful system that works, but is general enough to integrate both dpkg and rpm.

Puppet. I'm increasingly convinced that a multilevel system is required to solve this type of problem.

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.

Seemples.

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.

There are many reasons dpkg is inappropriate:

0) It shouldn't require sudo access.

1) It must support multiple versions installed side-by-side for different users.

2) dpkg only supports a fraction of the potential users. package.el supports them all by virtue of inclusion in Emacs.

Reply on news.ycombinator.com