Re: ELPA policy

[Stephen Leake <stephen_leake@stephe-leake.org>]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> For each package version there is a range (possibly sparse) of core
> versions on which the package is supported (or just should work).

For normal ELPA packages, that's true.

For core and tarball ELPA packages, they must work in each current Emacs
release (since they are in the release tarball). They may also support
some set of previous Emacs releases.

> While the intent to move as much as possible in ELPA can be understood,
> it leads to potentially more incompatibilities between important parts
> which can provide API by themselves.

Yes.

> So, there should be some compromise between "latency" of new features
> before they generally become available for use in packages and overall
> core stability.  To me, it seems that the latter is more important and
> it's better to keep infrastructure & library things in core, while
> moving everything that uses them for a concrete purpose to ELPA.

For normal ELPA packages, that's true. But this is partly why core and
tarball ELPA packages are being considered.

> If that in turn provides some API which others use, then we have
> package interdependencies and that is probably OK (but can lead to
> conflicts). 

A more flexible requirements spec may  be needed. For example, Debian
packages allow specifying a range of versions in the dependency; that
can reflect actual testing, and not rely on implicit promises of future
backward compatibility. Of course, it can also lead to false failures.

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

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

cc-mode is the core for a lot of similar C-like languages, so it
probably makes sense to keep that in core. But it would be interesting
to see what the consequences of moving it to a normal or tarball ELPA
package would be.

But if you mean things like parsers and xref support, then I agree.
Although ada-mode also provides its own parser ...

> - New libraries which are not supposed to be in very common use go to
>   ELPA first

> - Then they are probably promoted to core as they get mature and more
>   widely used - just to simplify their usage ("they will always be
>   available").

That's what tarball ELPA packages are for.

The only reason to move a package to actual core (ie emacs git, as
opposed to elpa git) is if some other core code wants to depend in it.

> - Major applications (like Gnus) and smaller ones always go to ELPA
>   (most probably we should also bundle them in a tarball, but keep
>   outside of the core).

Right; that's a tarball ELPA package.

> - If such an application provides things useful for other
>   applications, then it probably should extract that into a library to
>   go through the cycle oulined above (elpa --maturity--> core).

Yes.

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

-- 
-- Stephe