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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
>> package.el solves the problem that org-html.el no longer exists simply
>> by not adding org-mode-1.6 to the load path. Nor does it load
>> "org-autoloads.el". So, even though org-html.el is still around on the
>> hard drive, it is ignored by emacs.
>
> The same can be done with any other directory structure, in two steps:
> (1) put the new directory first in load-path, and (2) don't load
> org-autoloads.el.  Right?

Apologies if I have replied to this already -- getting confused.

Yes, it could be.


>> Now, as it happens, with the current directory organisation of Emacs, we
>> can solve the problem anyway, by doing the same trick in core. But,
>> currently, we don't.
>
> That's exactly what I meant: we can do this with any directory
> structure.  IOW the directory structure is not relevant to this issue.

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.

The point here is that load-path is *directory* based. As it stands, we
cannot exclude some files in one directory.


>> And this could only work for org.el *because* org is in it's own
>> directory with its own autoloads file. For seq.el, for instance, it will
>> not work.
>
> So one solution would be to provide a separate autoloads file for each
> package that lives on ELPA.  That again has nothing to do with the
> directory structure.  Right?  (There could also be other solutions.)

I think that it is evident that there could be other solutions. Emacs is
Turing complete so any computable solution that you can image is
possible. The question is which is easiest.

package.el already does all of this.


>> There are a few other things that package.el does, which it would be
>> shame to loose. It checks dependencies for instance. So, say, I
>> installed assess.el into Emacs core using package.el as I suggest, and
>> it requires a newer version of seq.el than is available, package.el will
>> bitch about this very early.
>
> I don't see why we'd have to lose this.  No one said we are throwing
> away package.el.  We are talking about _extending_ it.

Just so that we can keep a particular directory structure?


>> Bottom line: package.el is a better way of handling packages than core
>> which is a legacy. Moving wholesale to it is probably not worth the
>> effort (at least not in the short term). But supporting it in core
>> definately is.
>
> 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. Yes, it
needs to be taught new tricks and it needs to be -- it can't cope with
texinfo files, for instance.

Phil