el-get 1.1, with 174 recipes
Yes, you read it well,
recipes, and is now
1.1 release. The reason for this release is mainly that I have
two big chunks of code to review and the current code has been very stable
for awhile. It seems better to do a release with the stable code that exists
now before to shake it this much. If you’re wondering when to jump in the
water and switch to using
el-get, now is a pretty good time.
New source types
We now have support for the pacman package management for archlinux, and a way to handle a different package name in the recipe and in the distribution. We also have support for mercurial and subversion and darcs.
Also, apt-get will sometime prompt you to validate its choices, that’s the infamous Do you want to continue? prompt. We now handle that smoothly.
1.1, that really means
synchronous. That means we install one package
after the other, and any error will stop it all. Before that, it was an
active wait loop over a parallel install: this option is still available
No more failed to install
Exactly. This error you may have encountered sometime is due to trying to install a package over a previous failed install attempt (network outage, disk full, bad work-in-progress recipe, etc). After awhile in the field it was clear that no case where found where you would regret it if el-get just did removed the previous failed installation for you before to go and install again, as aked. So that’s now automatic.
Featuring an overhauled :build facility
build commands can now either be a list, as before, or some that we
evaluate for you. That allows for easier to maintain
recipes, and here’s an
exemple of that:
(:name distel :type svn :url "http://distel.googlecode.com/svn/trunk/" :info "doc" :build `,(mapcar (lambda (target) (concat "make " target " EMACS=" el-get-emacs)) '("clean" "all")) :load-path ("elisp") :features distel)
As you see that also allows for maintainance of multi-platform build recipes, and multiple emacs versions too. It’s still a little too much on the awkward side of things, though, and that’s one of the ongoing work that will happen for next version.
We are now able to
byte-compile your packages, and offer some more hooks
el-get-init-hooks has been asked with a nice usage example). There’s a new
:localname property that allows to pick where to save the local file when
HTTP method for retrieval, and that in turn allows to fix some
(:name xcscope :type http :url "http://cscope.cvs.sourceforge.net/viewvc/cscope/cscope/contrib/xcscope/xcscope.el?revision=1.14&content-type=text%2Fplain" :localname "xscope.el" :features xcscope)
Oh and you even get
:before user function support, even if needing it often
shows that you’re doing it in a strange way. More often than not it’s
possible to do all you need to in the
:after function, but this tool is
there so that you spend less time on having a working environment, not more,
All in all, if you’re already using
el-get you should consider switching to
1.1 (by issuing
M-x el-get-update of course), and if you’re hesitating, just
join the fun now!