Emacs packages for programmers | Hacker News Reader

Emacs packages for programmers

nic.ferrier.me.uk

80 pointsnic-ferrier28 comments

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.

[1]: https://github.com/peterkeen/dotfiles [2]: https://github.com/dimitri/el-get

el-get is pretty cool but I think package has the following advantages over el-get:

1) it's standard emacs

2) although it doesn't have yet it will be able to support digital signatures for packages (as well as other security mechanisms)

As a developer of Emacs packages (it seems to be the only code I've written this year, outside of work) I am sticking with package.

I don't know how much the tips here might be relevant to el-get, I think not very.

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.

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.

Wow, that's a good point. I'm going to pull the stuff I use directly into my dotfiles repo.

hits the stop button on a stopwatch

And now people realize why I'm a luddite and just keep all my dependencies rolled into my dotfiles repo directly and have done so for years.

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".

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.

Emacs is no different.

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?

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 :).

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).

I have set up my Emacs so that it will automatically download and install all my favourite plugins if they are not installed yet.

So to set up a new machine, I simply copy my .emacs over and start Emacs. Emacs will then fetch and install all my plugins automatically. Quite handy!

Would you mind sharing your .emacs so we can see how you have that set up?

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.

It's pretty easy using package. Here's what I just copied and pasted from my init.el

  (require 'package)
  (dolist (source '(("technomancy" .   "http://repo.technomancy.us/emacs/)
                    ("elpa" . "http://tromey.com/elpa/)))
    (add-to-list 'package-archives source t))
  (package-initialize)

  (defvar my-packages '(starter-kit zenburn-theme auctex color-theme-solarized csharp-mode ecb_snap find-file-in-project flymake-css flymake-php idle-highlight ido-ubiquitous ipython python-mode magit markdown-mode paredit pastels-on-dark-theme php-mode rainbow-mode smex solarized-theme starter-kit-js zenburn-theme)
  "A list of packages to ensure are installed at launch.")

  (dolist (p my-packages)
    (when (not (package-installed-p p))
      (package-install p)))

Where you add the package name to my-packages. It's kinda cool to see it download and compile everything on a new install.

I would have posted my own setup, but it is all but identical to yours, so there you go ;-)

this is really neat. what would be cool is to keep the package list up to date automatically (possibly by advising package installation - https://github.com/nicferrier/emacs-package-store/blob/maste...).

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.

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.

You're right. I have renamed the article "Packages for Emacs Programmers"

Is there any advantage to MELPA? Why publish to MELPA instead of marmalade or elpa proper?

It appears there is less work for the publisher if they are using github.

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.

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.

Reply on news.ycombinator.com