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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Cc: address@hidden,  address@hidden
>> Date: Tue, 18 Oct 2016 14:33:50 +0100
>> 
>> >> 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.
>
> Look, this discussion will go nowhere constructive if you change the
> subject all the time.  You talked about load-path, and our inability
> to exclude files in directories on load-path.  Clearly, this only
> matters when Emacs wants to _load_ the file in question, and for that
> the order of directories in load-path is all that counts.


*shrugs*. I'm doing my best to be as clear as I can, I do not think I am
 changing the subject.


> Now you are evidently talking about a file that was already loaded,
> and then the user upgraded the package from which that file comes, and
> wants the new version to become effective without restarting Emacs,
> which is where the old features already loaded get in the way because
> the user wants their new versions.  Obviously, this has nothing to do
> with load-path, right?

No.

Consider this scenario.

Situation One:

Org-mode comes with a file called org-html. Org-mode v1 is distributed
with core emacs. Org-mode v2 is released, and user installs from ELPA.
Org-mode v2 is before Org-mode v1. The world is well.


Situation Two:

Org-mode v1 comes with a file called org-html. v1 is distributed with
core emacs. Org-mode v2, however, no longer has a file called org-html,
but does have a file called ox-html. Although org-mode v2 comes in the
path before org-mode v1, it is still possible to load org-html.


Situation Three:

Org-mode v1 comes with org-html. v1 is distributed through ELPA.
Org-mode v2 comes with ox-html. We upgrade v1 to v2, and v1 is removed
from the path. org-html is no longer loadable.


I mention this because it's happened to me. I was happily loaded
org-html even though I had updated org mode to latest in ELPA because I
didn't know.

We can solve Situation Two by simply excluding the org-mode v1 directory
for load path, but this option is only open to us because org-mode is in
its own directory.

My conclusion: having org-mode its own directory is a good thing. By
extrapolation, therefore, having most or all packages in their own
directory would be a good thing.


>> More generally, you might also concieve of a situation where a new
>> package replaces another.
>
> If package.el already knows how to unload the old features and load
> the new ones, it will continue doing this for any package, whether in
> or out of core.  Right?

With the example that I have given, this fails at the moment for
org-mode, specificially because org-mode is in core.

Phil