Re: ELPA policy

[Stephen Leake]

Filipp Gunbin <address@hidden> writes:

> 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), 

Yes. We have not implemented this yet, but I'm imagining there is a list
of these in the Gnu Emacs Makefile somewhere (probably in a separate
file read by the Makefile). I don't think there will need to be any
metadata in the package files for this.

Declaring an ELPA package to be a tarball package does impose some
restrictions on the package maintainer; they have to synchronize with
each Emacs release, and accept the same review/oversight as core code.

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

I don't see why that is different from depending on a normal ELPA
package. 

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

Emacs does not support multiple versions of packages available
simultaneously; there is only one instance of a package that is first in
load-path.

You can end up with one copy in the installed Emacs distribution, and
one in ~/.emacs.d/elpa. But the elpa one will take precedence; that is
the only one that other packages have to worry about. It either meets
their dependency requirement, or not.

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

That's the main reason to make a package available in both core and ELPA:
users of the released version of Emacs can use the latest version of the
core ELPA package from ELPA, overriding the copy in their installation.

>>> 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)
>
> No-no, what I meant were Emacs Lisp libraries extending language, like
> seq.el.

That's a good candidate for a core ELPA package.

-- 
-- Stephe