Re: ELPA policy

[Stephen Leake]

John Wiegley <address@hidden> writes:

>>>>>> Stephen Leake <address@hidden> writes:
>
>> ELPA packages that other core code depends on (like CEDET; xref uses it -
>> called "core ELPA packages" hereinafter) have to be in every developer's
>> build environment everyday; the other core code has to see the current
>> version of the package, and it has to be the same for every developer.
>> 
>> If core ELPA packages are in the ELPA git repository, you would copy some
>> subtrees of the ELPA git workspace into the Emacs git workspace. People have
>> looked into doing this, but it gets messy and confusing. "git fetch" is
>> dealing with two upstreams for one workspace. There has been talk about git
>> submodules, etc, but nothing concrete.
>
> Elpa.git should be a submodule referenced from within Emacs.git (under
> "elpa").

That's overkill; there are many packages in Gnu ELPA that core code
should _not_ depend on.

We could try to have a list of approved packages in a file somewhere,
but I don't think we can enforce that; better to use git to enforce it.

We need a way to explicitly label and enforce which ELPA packages core
code can depend on. The only demonstrated way to do that is to keep them
in Emacs git.

> This allows us to expressly state which "version" of Elpa is expected
> to work with the current Emacs.git.

That's only required for the ELPA packages that core code can depend on.
For the other ELPA packages, we explicitly don't want to know if they
work with Emacs master; that's up to the individual package maintainers.
That's one of the primary purposes of ELPA.

> Large packages like CEDET should move outside of Emacs.git and into
> Elpa.git.

If this said "large packages that the rest of Emacs core does not depend
on ...", I could agree.

I just checked; the only other core code that depends on CEDET is
xref.el, which can be fixed. So I agree, CEDET should move to elpa git.

However, I assume the reason CEDET is in Emacs git is because there is a
desire to distribute it in the tarball; a sufficient number of users
expect it to be there without going thru package install. So the
mechanism to put ELPA packages in the tarball (but _not_ in the emacs
development workspace) must also be implemented. That should not be too
hard; no git submodules, just directory tree copy.

So this introduces a third kind of ELPA package: "distributed in Emacs
tarball". A "tarball package" for short?

Except that Eric maintains that there is more to "CEDET" in Emacs core
than just lisp/cedet/*. So to be clear, we are proposing to move only
lisp/cedet/* to elpa git.

> If xref.el depends on CEDET, it would move to Elpa.git as well.

As Dmitry points out, better to remove the dependency from the core
xref.el. Then we can add it back either in the ELPA CEDET package or in
a new xref-cedet ELPA package.

>> If we use the approach of keeping core ELPA packages in the Emacs git
>> repository, there is _zero_ friction for the current core Emacs developers;
>> the only change is in the ELPA config scripts.
>
> I do not want this code replication. 

How is it replication?

There are two styles of ELPA packages currently:

1) The only repository for the code is Gnu ELPA git

2) There is an external repository that the package maintainer uses;
   releases are pushed to Gnu ELPA git

The choice is up to the ELPA package maintainer.

The proposal is to change both to say:

1a) The only repository for the code is Gnu ELPA git or Gnu Emacs git.

2a) There is an external repository that the package maintainer uses;
    releases are pushed to Gnu ELPA git or Gnu Emacs git.

The ELPA packages in Emacs git are "core ELPA packages"; core Emacs code
may rely on them. 

There is no additional replication by keeping the core ELPA packages in
Emacs git.

The only reason the core Emacs packages are in the ELPA server is to
allow package releases in addition to Emacs releases. The package
maintainers have to accept maintaining backward compatibility, so a core
package in an Emacs 25.1 binary install can work with a more recent
version of the core ELPA package.

In summary, I'm proposing that there are three kinds of ELPA packages:

1) "normal ELPA package". 

    - Stored in Gnu ELPA git, and possibly in the package maintainer's
      separate repository.

    - Releases only occur via the ELPA package server, whenever the
      version number increments in the ELPA git main package file.
    
    - Core Emacs code may not depend on these.

2) "tarball ELPA package". 

    - Stored in Gnu ELPA git, and possibly in the package maintainer's
      separate repository.

    - Each Emacs release includes a released version of the package in
      the Emacs tarball, via copy from an ELPA workspace at Emacs
      tarball build time. Other releases also occur, via the ELPA
      package server, whenever the version number increments in the ELPA
      git main package file.
    
    - Core Emacs code may not depend on these.

3) "core ELPA package".  

    - Stored in Gnu Emacs git, and possibly in the package maintainer's
      separate repository.

    - Each Emacs release includes a version of the package in the
      tarball, because it is in the Emacs git workspace. Other releases
      also occur, via the ELPA package server, whenever the version
      number increments in the Emacs git main package file.
    
    - Core Emacs code may depend on these.

-- 
-- Stephe