Yes, you read it well, el-get currently features 174 recipes, and is now
reaching the 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.
(el-get 'sync)
In 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
through calling (el-get 'wait).
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
The 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.
Misc improvements
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
using HTTP method for retrieval, and that in turn allows to fix some
recipes.
(: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,
right? :)
Switch notice
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!
Tags
Previous Articles
- Extensions: writing a patch for PostgreSQL Friday, October 15 2010, 11:30
- Introducing Extensions Thursday, October 21 2010, 13:45
- pg_basebackup Sunday, November 07 2010, 13:45
- Dynamic Triggers in PLpgSQL Wednesday, November 24 2010, 16:45
Next Articles
- Starting afresh with el-get Tuesday, January 11 2011, 16:20
- Going to FOSDEM Tuesday, February 01 2011, 13:35
- Back from FOSDEM Monday, February 07 2011, 11:10
- desktop-mode and readahead Wednesday, February 23 2011, 16:45

