Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> Date: Fri, 30 Sep 2016 11:43:10 +0100
> 
> > EZ> We should at least try, IMO, and not dismiss that possibility before we
> > EZ> really see the difficulties and can assess them.
> >
> > I agree with Eli here. The more "natural" we can make the ELPA integration,
> > the better I think it will be, since it will allow the flexibility for 
> > either
> > approach, depending on what is best.
> 
> Sure, but it cannot change the fact that ELPA and Emacs core have
> different organisations because Emacs has a unified (or monolithic
> depending on your POV) directory structure, while ELPA has a
> per-package structure.
> 
> 
> So, we have
> 
> EMACS/lisp/blah.el
> EMACS/test/lisp/blah-test.el
> EMACS/doc/emacs/blah.texi
> 
> While ELPA has
> 
> ELPA/packages/blah/blah.el
> ELPA/packages/blah/blah.texi
> ELPA/packages/blah/test/blah-test.el
> 
> (actually, the test location for ELPA packages is not standardized, but
> it should be).
> 
> So, we can either:
> 
> 1) Have both of these organisations
> 2) Move EMACS to the ELPA organisation
> 3) Move ELPA to the EMACS organisation
> 
> My suggestion is 1).

My suggestion is none of the above.  We should instead try to arrange
things so that when a Emacs is built from the repository, the build
process updates any packages from ELPA that need to be updated, as
part of the build.  And when an Emacs release tarball is tarred, each
package has its files put/updated in the corresponding directory under
lisp/.  If we succeed doing this, there will be no difference between
packages in the Emacs repository and in ELPA, as far as building and
releasing Emacs is concerned.

Can we try doing that?

> After that, where blah.el is a package in core format, and foo.el is a
> package in elpa format, we can do:
> 
> a)
> 
> EMACS/lisp/blah.el
> EMACS/packages/foo/foo.el
> 
> which is nice because it cleanly separates out the two layouts.
> 
> b)
> 
> EMACS/lisp/elpa/packages/foo/foo.el
> EMACS/lisp/unified/blah.el
> 
> which also seperates the two layouts, but would require lots of file
> moves form the current system.

Why do we need to separate them?

> Or c)
> 
> EMACS/lisp/blah.el
> EMACS/lisp/elpa/packages/foo/foo.el
> 
> which keeps all the lisp files under the lisp top-level dir, does not
> require file moves, but pushes the two directory structures together,
> complicating the build.
> 
> For me, I think that the second b) is the ideal, but moving lots of
> files to get there is not worth the effort. Hence I like option a). I
> think c) will result in confusion of developers (as well as the build
> system).

For me, this is the ideal:

  EMACS/lisp/blah.el
  EMACS/lisp/foo.el (or EMACS/lisp/SOMETHING/foo.el)
  EMACS/doc/misc/foo-user.texi
  EMACS/doc/lispref/foo-elisp.texi

etc., where SOMETHING is one of the _existing_ subdirectories under
lisp/, as might be appropriate for foo.el's topic.