Re: package.el, auto-installation, and auto-removal

[Robert Dallas Gray]

As an addendum to the points that have been raised on this topic, and as the 
author of Pallet, I thought it worth chipping in a few tuppences. 

There are several solutions to the problem Stefan outlines, with varying 
degrees of complexity and flexibility. To my mind, Cask is the least complex 
and most flexible. 

Cask only requires Python when used from the command line. There is a version 
available as a package.el package; this is what Pallet uses as its backend.

Pallet, as has been stated, is a dirt-simple layer over Cask, which rewrites 
the Cask manifest when the user installs or deletes packages using the 
package.el subsystem.

Pallet doesn't yet support version-controlled packages (outside of the 
package.el ecosystem), but Cask does. Pallet will also, when I have time.

Cask uses a tried-and-tested text-file manifest strategy, which has worked well 
for, e.g., Ruby's bundler and Javascript's npm. The syntax is a subset of Emacs 
Lisp.

Cask's author, Johan Andersson (https://github.com/rejeep) has also written epl 
(https://github.com/cask/epl), a layer over package.el which abstracts the 
package.el api, and servant (https://github.com/cask/servant), a mock 
package.el server. He knows the vagaries of package.el very well indeed.

I don't really have a dog in this fight, as I respect the authors and codebases 
of elpakit, Cask and use-package equally (I don't know enough about el-get to 
have an opinion), and as Pallet is so functionally trivial. 

But from the point of view of testability, at least, I've had success with 
using the Cask/epl/servant ecosystem to develop a package, and a set of 
integration tests which work across several Emacs versions (not so trivial). So 
I'll throw my hat in the ring for something like Cask and something on top of 
it like Pallet, even if it's neither of those actual things.

I think a consensus on something simple and flexible would be a great thing for 
Emacs.

Robert Dallas Gray