Re: feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Andy Moreton <address@hidden> writes:
>> But Org already supports those two formats.  We don't require Org to
>> do anything that it doesn't already do.  So staying with the current
>> structure of lisp/ in the Emacs tree doesn't add any new requirements.
>
> But that would do nothing to reduce the unnecessary and duplicated
> packaging work.
>
> Keeping each package in ELPA format ensures that replacing the package
> can be done easily, as everything is isolated in a single directory. If
> the package is shipped in the emacs tarball and the user then upgrades
> to a newer version from ELPA, only the load path needs to change.


Yes, this is precisely my argument. Each elisp package should be
packaged in one and only one way and used in this way. Anything else
adds complexity for the developers of that package that is unfortunate.

Given that package.el provides a packaging solution that we already use,
adding it to the core build enables this simply and straightforwardly.


> In additon, the user can easily compare the changes bewteen the package
> version shipped in the emacs tarball and the updated one fetched from
> ELPA, as the package layout is the same.
>
> There are many more users of emacs than developers, so the design
> should be aimed at utility and convenience for users.

In this case, I am not sure this is so relevant; or, rather, it is
highly dependent on what you mean by "users". My belief is that the real
end users should see no difference at all. So the cost-benefit is
between the developers of individual packages, the developers of core
Emacs, and the developer of the build system.

My belief is that the first group win without cost from my proposal.
The second group, I think also win, especially if we can use some git
cleverness to make the core and tarball ELPA packages easy to update via
vc (i.e. some git submodule type of thing). And for the latter, it's not
clear; we have to offset getting package.el into the build system (which
I have proof of principle), against that of moving files around the
source tree, then building as usual.

Phil