Package Management Across Machines

Daniel Szmulewicz has an interesting post up on his blog about managing Emacs packages when you have multiple machines that you want to keep configured identically. He went through the usual cycle of solutions: First, he managed it by simply copying over his init.d to each of the machines and then loading whatever packages he needed from ELPA or other sources. Then he put his .emacs.d under version control but he found that objectionable because he was putting external code under version control. Next he wrote a bit of Elisp to load a list of packages, put it in his init.d and put just that under version control.

That's where most of us would have stopped but he asked himself how he could also automate deleting packages. He found a very nice solution using el-get that handles both adding and deleting packages according the one simple list in his init.el. If you're trying to maintain the same Emacs configuration on more than one machine, you may find his solution useful. Definitely worth a look.

This entry was posted in General and tagged . Bookmark the permalink.
  • A combination of symlinks (for .emacs.d and .emacs) and Dropbox works quite well for me. I am not sure it works quite as well when you also have Windows machine though since I only have two Linux machines. Also, for some people Dropbox might be a no-go.

  • I use a combination of Linux, OS X and (for work) Windows. My solution also relies heavily on Dropbox and symlinks, and I have not found any major concerns. My largest complaint at the moment regards the slow file IO thanks to cygwin- magit in particular sees a tremendous slowdown. However, I'm always game to save some space in Dropbox- to cut the needless pollution and economic drain, perhaps. I will certainly be seeing how far I can stretch the methods here.

  • Same here: Dropbox, symlinks (also on Windows) and no major (or even minor) issues. All being used on Linux, OS X and Windows frequently.

  • Phil

    FWIW, I wouldn't recommend any solution which (a) relies upon external sources being accessible at the time you are replicating the configuration, or (b) might not install the exact same version of each library that you were using previously.

    The latter could lead to unexpected 'upgrades', which might easily break your config. The former would just fail to install something, again, potentially breaking your config. Either case will cost you time.

    If you're deciding on a replication solution, make sure you pick something which is guaranteed to give you a working configuration.