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

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> Pallet hooks (through advice) into package installations, plus it can
>> discover the starting list of packages. It then maintains a Cask file.
>
> OK, next question: what's a Cask file?
>
>> So it does what you asked for at the beginning of this thread, but
>> relays the actual package management to Cask.
>
> You mean package.el isn't actually used?
>
>> Cask manages a list of packages in an external file. It's aware of
>> dependencies, repos, etc. and is quite popular for its ease of use.
>
> "Aware of" isn't sufficient for me to understand what it does with that info.
>
>> As Phillip Lord said, bundling Cask would remove its Python
>> requirement and perhaps improve the user experience with package.el
>> and the various ELPAs.
>
> What functionality does it provide for the user (other than
> auto-removal of the packages that were not explicitly installed, and
> the ability to install the same set of packages, obviously)?


So, a brief outline of the various mechanisms for managing packages out of band.

Cask is a package (with a small python launcher) that uses a "Cask"
file. This is the cask file from cask itself.


(source gnu)
(source melpa)
(package-file "cask.el")
;; (files "*.el" "bin" "templates")
(development
(depends-on "f")
(depends-on "s"))

It looks like Lisp but actually isn't; you can't put conditional
statements in it for instance. Emacs reads it, and installs the
relevant files, using package.el to do so. Cask can be used to
configure your "daily" emacs. You can synchronise between several
machines by just syncing your Cask file, and then running "cask
install" which will pull down all the relevant packages. I do not use
Cask for this purpose though.

It also lets you run Emacs in batch, with a "sandbox" load-path; I use
this to run unit tests both locally and on a continuous integration
server. For this use, cask also integrates nicely with evm, which lets
you tests for several versions of Emacs. I do use cask for this, and
find it works well.

Pallet is a package which advices the interactive features of
package.el. When you install a package, it also writes the Cask file
for you. I don't use pallet myself. So, it provides a GUI mechanism
for managing your Cask file.

In both cases, there is not specific support for deleting unused
packages, although the data is there. In practice, you can just delete
your elpa directory, and then run "cask install" to pull the stuff you
need again.

For myself, I John Wigely's use-package -- it provides a nice
convenient way to configure and customise packages (something that
Cask does not). So, you can do something like this...

(use-package ace-jump-mode
  :bind ("C-." . ace-jump-mode))


It also has an ":ensure" keyword. So 

(use-package ace-jump-mode
  :ensure t
  :bind ("C-." . ace-jump-mode))

Will ensure that the package is installed and do so if not. I like
this because I can just sync my .emacs file between (which I am going
to do anyway). When I want to use a new package, I add a use-package
statement to my .emacs, and the package installs on my machines next
time I start Emacs. This works nicely, although I would quite like a
command line tool for managing packages, it doesn't seem worth the
effort of moving to Cask at the moment.

At the moment, I have not tried elpakit. Sorry, Nic, I probably will
give it a go now.

I think that any of the solutions would work. What is interesting is
that both Elpakit and Cask have additional stuff added. I've been
really glad to get Cask working and have it running my test cases for
me, outside of my daily emacs. But it's not strictly necessary for
persistantly managing packages.