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

[Nic Ferrier <nferrier@ferrier.me.uk>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> It would be nice to keep it as a directory structure because they are
>> easier to edit:
>> .emacs.d/elpa/
>> .emacs.d/elpa/archives/
>> .emacs.d/elpa/archives/marmalade/
>> .emacs.d/elpa/archives/gnu/
>> .emacs.d/elpa/archives/user-installed/
>> .emacs.d/elpa/archives/user-installed/elnode
>> .emacs.d/elpa/archives/user-installed/rcirc
>
> I was thinking of keeping it in a Custom var, since that's easy to edit.
> So the equivalent of a Cask file could look like
>
>    % cat CaskNG.el
>    (setq package-archives ((gnu ...)
>                            (melpa ...)))
>    (setq packages-installed '(dash foo bar))
>    ...
>    %
>
> and you could run your tests with something like
>
>    emacs --batch -l CaskNG.el -f package-install-packages ...

I don't think a custom var is as good as something persistent in the
file system. It would be completely orthogonal to the existing data
storage which is all in the elpa dir (even the package-archives variable
is just an index of what is actually stored nicely in the elpa
directory, you can't recreate it wholly from there, but it's good
enough).

Great that you used a cask example. Because you'd actually need python
to run that. Hurray!


> So, my request is for someone to help set up the core of this, i.e. add
> the `packages-installed' var (automatically updated by
> package-install/delete and friends (I notice now that package-delete is
> not a command, surprisingly)), and add the package-install-packages
> command (so users can install their packages on a new system simply by
> setting packages-installed and then running package-install-packages).
> Bonus points for writing `package-gc' which deletes packages not
> required by packages-installed.

Yeah, as I say elpakit already has this. I could extract the code.

One thing about elpakit's solution is that elpakit does this by making a
package with the right dependencies.

Elpakit's solution is in fact just a package depend builder. Choose X, Y
and Z packages and then make a new package depending on those.

Maybe the current package installed by user state could be constantly
regenerated as a package.

The reason elpakit does that was in response to teams of clojure users
who wanted to homogenize their emacs config. So we made a system where
they could generate a base package to pull in all standard packages. And
then they could all iterate on top of that.

So making a new package all the time would be kinda useful because you
could easily share it with other people.

What do you think of that idea?


Nic