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

[phillip.lord@russet.org.uk (Phillip Lord)]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>
> EZ> But in any case, having a separate sub-directory for every package, like
> EZ> what we have on ELPA, makes very little sense for a structure distributed
> EZ> in a release tarball. You'd have many dozens of subdirectories, each one
> EZ> with one or a handful of files.
>
> +1
>
> It also occurred to me that we don't need a "mapping" file: We can impose the
> constraint that any ELPA package to be included in the distribution use,
> within its package, the same directory layout it would like overlaid into the
> distribution.
>
> I don't see why this issue is generating so much discussion.

It's generating less discussion than the one about curly quotes, so I
think we are doing okay.

> We've decided we're not changing the directory structure for now.
> Supporting a single layout in the final tarball is not hard. Why the
> push to cater to package.el?

Because it's neat, simple and makes sense.


> If a user installs Emacs from the tarball, and then wishes to use Org-mode
> From ELPA rather than the distribution, they'll do what they'd do today: Use
> M-x package-install to install a newer version of Org-mode in their package
> directory, shadowing the Org-mode we included in the distribution.

Except that it doesn't. Try this. Take Emacs 24.3, M-x package-install
org. Now do, M-x load-library org-html. As you might expect org-html is
duly loaded.

This is unfortunate indeed because org-html is NOT in org any more. It
is still in the load-path though, and so still gets loaded. So, now we
have two versions of org loaded at the same time.

Of course, we could have package.el do cleverer things. It could realise
that org mode is also in core. It could therefore remove the core
installed org-mode directory from load-path. This would work for org, of
course, but only because org has its own subdirectory.

package.el could also check for existing autoloads. org-export-as-html,
for example, defined in org-html doesn't exist any more either, but, for
Emacs 24.3, its in the autoload file. Does package.el remove old
autoloads that are not shadowed? I don't know.

Alternatively, if org in core were in package.el format, package.el
could just not initialize the package in core. Never gets added to
load-path, autoloads never get loaded. package.el can use *exactly* the
same technique it uses when multiple version of org get installed into
~/.emacs.d/elpa.

> As far as I can tell, the only thing we need to support tarball ELPA is file
> containing a list of packages, and an addition to "make dist" that copies
> these packages into the distribution directory when building the tarball. Or
> am I missing something?

Each one in their own directory?

I think it's decision time. I am happy to carry on a little further with
the package.el based approach that I have outlined, fixing the one
significant issue with it and then I will stop. If you don't want to go
this way, that's fine.

Phil