Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Alain Schneble <address@hidden> writes:
>> I was talking about using package.el as part of the build process to
>> compile package, and then using package.el as part of startup to
>> initialize packages in core.
>
> Where the code used to drive the build process comes from is a separate
> question and isn't really relevant for the concerns I have.  But the
> final results (incl. directory layout) matters, IMHO.  And with the way
> you propose to use package.el it matters because it brings in a new
> directory layout just for the ELPA core packages.

Yes, I would agree, although without the "just". I'm hoping that ELPA
becomes a more critical part of Emacs.


>>> If we stick to the Emacs directory/file layout, it is a unified layout
>>> that gets presented to her. Where distictions between core libraries
>>> and ELPA core packages aren't visible at that level. That would be
>>> worth trying to achieve, I think. (And in fact is how the
>>> directory/files organization looks like in the current release, IIUC.)
>>
>> AFAICT the layout of files inside the Emacs directory is, or should be,
>> more or less irrelevant to the end user of Emacs. We do not need to
>> maintain the current directory structure, to maintain the user
>> experience.
>
> I don't think it's irrelevant.  But that's me.  Having a unified
> directory layout certainly is a good thing, I think.  And as long as not
> all Emacs built-in libraries are ELPA core packages, I'm more towards
> keeping the current structure than bringing in a new one side-by-side.
> (And AFAIU, making all libraries ELPA core packages isn't even a
> long-term goal...)

"All libraries" isn't possible unless the bootstrap process is
re-written, but aside from that, I would think that having all packages
in package.el format would be a good thing, but that moving to it may
not be worth it.

Phil