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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
>> Eli, I think you are not taking the time here to understand the problem.
>> Both Achim and I have thought the issue through
>
> Those kinds of remarks are hardly constructive.  Please assume that
> I've thought the issues through as best I could,

If you will assume the same, yes, of course.

>> and it restarting Emacs were the solution then neither of us would,
>> I expect, be complaining.
>
> I don't see why restarting won't be a solution.  If load-path was
> re-arranged to put the latest version of a package first, and the
> package's autoloads are on a file that has been regenerated, what else
> is missing to make restart the correct solution?


Again, only if the file names have not changed between one release and
the next. This is an assumption which is not true. And, anyway, it's not
possible to regenerate autoloads in core emacs.

>> As Achim says, an org-html in the core installation cannot be removed
>> because it comes as part of a packaged Emacs and needs admin
>> privilleges; again, can be done, but not very good practice. The
>> org-html in core can be shadowed but only by another file called
>> org-html. More recent versions of org do not contain such a file.
>
> If load-path is rearranged when a newer version of Org is installed,
> and org-loaddefs are regenerated, then, after a restart, any 'load'
> and 'require' will find the new files first, and the old ones will be
> effectively invisible to Emacs.  Right?

No. They are still there, and are still visible, as long as they are in
the load path.


>> There are solutions to this, many of them hacky. The simplest solution
>> is to NOT include the directory containing the old version of org in the
>> load-path.
>
> That solution will only work for packages in their own directories.

Yes, hence my assumption my argument that packages in their own
directories is a good thing.

> We want to have a solution that works even for files in common
> directories.  I think rearranging load-path and regenerating the
> autoloads will solve that as well.

As discussed rearranging the load path does not solve the problem, and
regenerating the autoloads isn't possible.


>> It will not, and does not.
>
> Why won't it?  (The "does not" part just means package.el doesn't
> currently do that, AFAIU, but it can be extended to do it.)

load-path is directory based. I cannot prevent files that could be
loaded from core, unless they are in one directory.


>> I will leave it there. If neither you or John want to go this way, I
>> will stop.
>
> I think we both indicated that we want to go this way, we just don't
> want the Lisp files scattered among dozens of directories, each one
> with a single file.  Yes, this is a goal that is harder to achieve,
> but I don't yet see any fundamental difficulties on that path, just
> some more work.

The fundamental difficult is that we are supporting two different file
arrangements for any package present in core that can also be installed
from ELPA.


> I think making such a change incrementally is worse than doing it at
> once, as far as the directory structure is concerned.  We don't want
> to change the directory structure several times, ideally not even
> once.  But if some change is required, it should be done in one go, so
> we need to decide on the structure up front.

That, of course, is also a possibility, and one that I would be happy to
consider.

Phil