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

[Alain Schneble <a.s@realize.ch>]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Alain Schneble <a.s@realize.ch> writes:
>
>> 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!

Good idea. Why not.  I just doubt that many packages will ever require
this.

>>> 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.

Ok.

>> 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.

Alright.  But look, no one prevents us from removing the old version
from load-path, for packages that have their own directory.  Large
packages happen to have their own directory anyway.  For single file
packages, the issue is non-existent, as renaming such a file is not
really a use case as it would essentially introduce a new package
(name).  And then there may be a bunch of (smaller) multi-file packages
that could run into such a "deleted-file-issue".  But keep in mind that
all bundled core/tarball packages are from a trusted source and we can
circumvent or fix these problems (in the worst case with explicit
mechanism we have discussed).  It's in Emacs control.

So I think that legitimating a separate directory for each structure
using this edge case sounds like nit-picking.

> 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.

It's there and we fortunately can extend it.

> 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?

IMHO, trying to implement the simplest possible file structure and not
introducing a new one but reusing the existing one, are reasons enough.
Also, having a dual directory layout in released Emacs tarballs doesn't
feel good to me.  And to my understanding, we haven't seen a road block
with the "integrated" ./lisp layout so far.

Alain