Re: ELPA policy

[Filipp Gunbin]

Stephen,

On 11/11/2015 15:22 -0600, Stephen Leake wrote:

>> If sufficient amount of important packages use some API and that API
>> is rather mature, then the maintainer can decide to move that in core
>> to simplify dependency management.
>
> or to a tarball ELPA package, or to a core ELPA package.
>
> Perhaps that is too much choice?

Mm yes, that's one of my fears, that it will become too complex for a
package maintaner.  Why not just treat each ELPA package just as an ELPA
package and leave the option of bundling it to core maintainers which
are better in this area (they'll do it in agreement with package
maintainer, of course)?

A "tarball" ELPA package is a one thing (that's what I call "bundle into
tarball", if I understood right), but "core" ELPA package is another -
here I have another fear, that normal and tarball ELPA packages
depending on such "core" packages, will have to accurately define
versions of the core package they support, and then we have to check all
this during the installation.  We'll probably have to calculate and
offer to user which set of the multiple core packages' multiple versions
suits for multiple normal and tarball (perhaps overriden by version from
Internet package archive) packages, at the same time probably giving the
user to opportunity to specify her preferred version of each requested
package.  Is it worth the trouble?  Or do I understand something wrong?

That's why I wrote about the feature latency - maybe it would be enough
if a person willing to use latest core features in her package will have
to develop it on git emacs and wait for the next official release to
make her package available to the public.  This will be the same as with
new C level features, which we cannot "push quicky" as we can with ELPA
package.

>> So, I'd suggest that:
>>
>> - Language features go straight into core (and people working on them
>>   / using them will have to use git version of Emacs until next
>>   release)
>
> By "language features" do you mean things like ada-mode.el (primary mode
> for editing Ada source files)? If so, I strongly disagree; ada-mode.el
> is very happy as a normal ELPA package. Similar modes for other
> languages with a small audience could be in ELPA as well; I have not
> looked to see what's actually there.

No-no, what I meant were Emacs Lisp libraries extending language, like
seq.el.

>> The API / SPI notion can also be used to provide implementations
>> (backends) for different features which may have default simple
>> implementations in core and more advanced ones in packages.  A package
>> must somehow "register" itself as a candidate for being a service for
>> a concrete feature during installation.
>
> If we use cl-generic to provide dispatching, the cl-defmethod form does
> the registration.

Thanks, that's one more reason for me to become acquainted with Emacs CL
features.

Filipp