overtone/live-coding-emacs — pull request #19 by DanielJomphe (2012-04-25 02:20:23+00:00)
Title: Using ELPA where appropriate

I recently started using Live Coding and _love_ its impact on my daily usage of Emacs for Clojure development.

That said, doing so complicated quite a lot my `.emacs.d` when I compare it with what I had to keep in my GitHub dotfiles prior to using Live Coding. I was used, thanks to ELPA, to have a single `init.el` file that automatically downloaded and installed all my Emacs packages on demand if they weren't already there in my `emacs.d`. This was a very neat setup.

Live Coding, on the other hand, (necessarily but hopefully temporarily) comes with more moving parts. Consequently, I started experimenting on how we could converge back towards a single (or a small number of) `init.el` file. A first step in this direction would be to remove many packages in Live Coding's `lib` folder without denaturing Live Coding in any way, by making ELPA manage them instead of having you maintain them in Live Coding's `lib` folder like you do at present time.

I see you recently started to use Emacs 24's pre-release, which comes with [ELPA](http://tromey.com/elpa/faq.html) built-in. (ELPA is also [compatible](http://tromey.com/elpa/install.html) with Emacs 21, 22 and 23, but must then be installed manually.) Would you be interested for Live Coding to start using ELPA to automatically install, compile and manage those packages for which it seems appropriate to do so because they're available there and their impact on Live Coding's configuration is invisible? If so, please check the following commits. This pull request only includes conservative replacements. I spent quite some time making sure each one of them is atomic in its impact on Live Coding. (I could add more commits if you want when I'm done making sure they don't introduce regressions.)

Of course, pulling this right now into Live Coding would make it less easy for users of Emacs 21-23 to start with Live Coding (unless Live Coding bundled package.el for them!).

I'd be happy to hear what you think about this; and cheers for your great Emacs distribution/config!