Re: ELPA policy

[Filipp Gunbin]

On 12/11/2015 13:52 -0600, Stephen Leake wrote:

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

They'll just have to make sure that a single version (which is going to
be bundled in a tarball) works good with an Emacs release being
prepared.

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

I think it's their dependants what make them different from tarball and
normal packages.

Emacs core provides API, which others use.  A normal package declares
which versions of this API it is supposed to work against.

With core packages, Emacs still provides API, but it now consists of a
static part (C level & core) and dynamic part (core packages, which can
later be updated from ELPA - correct me if I'm wrong).  So, a package
should independently define which core version it works agains and which
core package(s) version(s) it works against.

Here's where I see the complexity with multiple packages installed on
user request with package manager, which I tried to describe below.

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

Of course, I was talking about the set of available versions which could
be installed and from which a user or a package manager should choose.

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

Yes, but it can introduce complexities I wrote of above.

Filipp