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

[Alain Schneble]

address@hidden (Phillip Lord) writes:

> Alain Schneble <address@hidden> writes:
>
>> Alain Schneble <address@hidden> writes:
>>> Exactly, I see it the same way.  I also think it's as a separate issue
>>> (that after all could also be handled by each package separately if it
>>> needs to solve it at all).
>>
>> To elaborate what I wrote in parenthesis in the last sentence above: In
>> this situation, the new package could still (provide
>> 'the-deleted-feature) or register a function to be called when loading
>> such deprecated file using after-load-alist or somesuch.  The former
>> could make a (require 'the-deleted-feature) a "noop", the latter could
>> raise an error, or whatever.  And there are for sure other feasible
>> approaches that could be implemented by a package if required.
>
>
> Just to clear, you are suggesting that when moving from org-html to
> ox-html, the org developers should have had a file called org-html.el
> like so:

Let me back up first before answering this.  I fully agree with what Eli
said, that if there is a problem, it's not within a single package that
got updated.  Because the updated package won't load a removed file or
if so, then it is simply a bug.

Now if there is another package or some "loose fragment" of code that is
requiring/loading the old feature/file that is no longer present in the
new version, then it's really an inter-package dependency problem.  And
you will always be able to construct cases that won't work properly.
Regardless of the chosen directory structure.

The point I'm trying to make is that if a given package wants to account
for such "misuses" explicitly, it is free to do so.  And there are
feasible solutions to this that a package can choose to provide if it
wants.

> (error "org-html is now deprecated")
> (provide 'org-html)
>
>
> Yes, that would work, but does not provide a good solution to my mind.

Yes, that is one approach.  The other I proposed is using
after-load-alist:

Extract the example in the attached file.

deprecated-feature-example.gz
Description: deprecated-feature-example

- emacs -Q

- Eval the following fragment, after having replaced [path-to] to the
  proper path where the example was extracted to:

  (push "[path-to]/deprecated-feature-example/foo-package-1.0" load-path)
  (push "[path-to]/deprecated-feature-example/foo-package-2.0" load-path)
  (require 'foo-old)
  => an error will be signaled "foo-old is no longer supported..."

But don't get me wrong.  I really don't think this will be the usual
case.  In most if not all packages, accounting for such misuses won't be
required at all.  I just wanted to prove it's not an unsolvable problem.

Alain