Re: policy discussion on bundling ELPA packages in the emacs tarball

[Phillip Lord <phillip.lord@russet.org.uk>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> I solve this problem for my own packages by not installing them from
>> ELPA, but from their git repos. This means normal users and me as
>> developer have a different set up.
>
> Yes; package developers edit package code in an ELPA checkout; typically
> they will also run the code from there as well for testing, by putting
> that directory in load-path.
>
> But with bundled packages as submodules, they could switch to editing
> them in the emacs workspace instead.
>
> The main point is that other emacs developers can also edit the package
> files, to fix bugs or make changes consistent with some core emacs change.

Just so, and this would be a substantial win. It is something that we
get at the moment by having a monolithic repo with all its
packages. Having said that, most Emacs packages do not get this. There
are 3000 packages on MELPA and they just update themselves as new Emacs
versions come out.

An alternative solution would be strength and automate the links between
a package in a repo and package.el. So, package.el would be able to main
a local package that was stored in a git repo, would like to the source,
but would do all the autoload generation, putting into the path and so
forth.

>> straight.el solves this problem in a more principled way; the package is
>> the git repo, but then the package manager is completely dependent on
>> git.
>
> From https://github.com/raxod502/straight.el. That sounds useful.

The nice thing about is that it unifies package management. It worries
me slightly that Emacs will be saying "Emacs uses package.el to manage
packages and their dependencies". But, then when looking at bundled
packages, we are saying "Emacs uses submodules". Two different systems
to achieve the same thing.

But, moving to the straight.el model would be a big change, of course
and would require git to be available for Emacs to do any package
management. This isn't true for the Windows bundle, for instance.

Phil