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

[Phillip Lord]

Alain Schneble <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>> I like this, and it gives a nice error message of deprecation, and I
>> think that is good. But this is a solution which requires package
>> developers to explicitly support declarations of deprecation.
>
> Indeed.  But in case a package offers a public feature/interface to be
> used by anybody, including non-package code, such an explicit handling
> would be TRTTD, IMO.

Yes, I think that is true. I don't think that there is explicit support
for this form of deprecation in Emacs at the moment. We should write a
package and add it to ELPA!



>> Just removing "food-package-1.0" from `load-path` gives a less nice
>> error message, but it still fails fast, and requires no developer
>> support
>
> True.  But I don't think we have to account for all possible "misuses"
> and bugs.  We all run into issues.  But we have to try to not get biased
> by a specific problem one once had and which might have taken hours to
> fix

I try not to. It's just a problem that packages in core having when
upgrading from ELPA. It's a clear, specific. I've had it, true, and it
took me a lot of time to work out, but as Achim says so have other people.


> And I think this discussion has nothing to do with the directory layout.
> It's a different topic IMO, though you try to fix it with the directory
> layout.

It is a problem that a package.el based solution would not have, and
which it achieves through in a simple and straight-forward way, though
it's use of it's directory layout.

Personally, I consider the directory layout to be a side issue -- direct
use of package.el is the main issue. It's there, Emacs already supports
in for packages in ~/.emacs.d, and in site lisp, it's already plumbed
into startup and all the files in ELPA are already built with package.el
in mind.

To me using it is a slam dunk, as our friends over the pond like to say.
I am not at all surprised that people objected to my idea of introducing
a new top level directory is contentious -- that is why I asked the
question in the first place; I am a little surprised at the objections
to a per-package directory structure for these packages. So far, I have
only understood two objections: Drew's and Stefan's. Why would it be a
problem?

Phil