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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
>> I think that this is incorrect. In this case, we can do this with the
>> directory structure that we have at the moment, and for org-mode,
>> because org-mode is a) in a directory of it's own and b) has it's own
>> loaddefs. This is not true for many of the files in ./lisp.
>
> When I said "we can do this" I didn't mean "without any changes" or
> "for free".  We will have to make changes, both in how loaddefs are
> generated, and in the build.  My point is that these changes are not
> difficult, since we already do that for several distinct packages in
> the core.  We just need to do that for more packages, that's all.

Yes.

>
>> The point here is that load-path is *directory* based. As it stands, we
>> cannot exclude some files in one directory.
>
> I don't see any need to exclude files.  If a newer version of a
> package is installed outside of the Emacs lisp/ tree, the directory of
> that package needs to be earlier in load-path than the main lisp/
> directory and its subdirectories.  Again, not hard to arrange.

No, this doesn't work. The point is with the new exporter, org
introduced new files. The new ox-html.el would not shadow the old
org-html.el, however you organised the path. In otherwords, the org
package changed the features that it provided over time.

More generally, you might also concieve of a situation where a new
package replaces another. Same 


>> package.el already does all of this.
>
> Once again, package.el in its current form was never meant to be used
> in the capacity we are talking about.  So using it without changes for
> the job we are discussing is wrong, because it would mean to subdue
> our directory organization to decisions made for a completely
> different use case.
> 
> In any case, such a solution was already rejected, both by John and
> myself.  So let's not argue about this anymore; let's instead see
> which changes are needed in package.el to support the preferred
> directory structure in core, even when some of the bundled packages
> live on ELPA.


Okay. I may complete my branch anyway, just for completeness sake.



>> > We need to adapt package.el to the new needs.  It was not written with
>> > these goals in mind, so it needs to learn new tricks.  Throwing it
>> > away is not acceptable, but neither is blindly accepting its current
>> > assumptions, which were not designed for the use case we are
>> > discussing.
>> 
>> No, but it's current behaviour makes a lot of sense to me and is, I
>> think, better than the monolithic structure we have in ./lisp.
>
> Others, including myself, disagree.

Yes, that is apparent. No worries.

Phil