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

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: Eli Zaretskii <address@hidden>,  <address@hidden>,  <address@hidden>
> Date: Fri, 07 Oct 2016 17:29:08 +0100
> 
> Alain Schneble <address@hidden> writes:
> >> Not if we are using package.el to make the packages available. It is
> >> package.el which sets the load path, loads the autoloads file, that sort
> >> of thing.
> >
> > After all, what would we gain from using package.el to do this
> > bootstrapping for the ELPA core packages?
> 
> Packages in already in package.el format can be directly used within
> Emacs.

What do you mean by "directly used"?  Directly as opposed to what?

> This requires no changes in the file layout, and means that
> packages will only be built with a single system (i.e. both Emacs core
> and ELPA will be build with package.el).

Why would the Emacs build require package.el to do anything at all?

And what kind of build do you have in mind here?  We have:

  . build out of Git repo
  . build of the release tarball as distributed from ftp.gnu.org
  . build of the release tarball after updating some packages from ELPA

> As a secondary benefit, this means I can build and test an ELPA checkout
> directly as part of the Emacs build, which should be useful for finding
> regressions.

ELPA packages should be logically part of Emacs, just in a different
Git repo.  So this goal should be supported, of course.  But I don't
understand why it would require using a separate directory tree for
ELPA packages.

> It also, of course, means that files from ELPA would now be duplicated
> in core Emacs because they would have been copied.

??? Copied from where to where?  And why?  I don't understand why they
would need to be copied anywhere, they just need to be downloaded
directly to where they belong in the Emacs directory structure.

> So, when developing Emacs, there would be version controlled .el
> source files and non-version controlled copied .el files in the same
> location.

We already have that; see charscript.el.  Why having some moe
unversioned *.el files would hurt or be any different?

> You would have to remember to edit the former, but not the latter.

??? Unversioned files can be edited to your heart's content, they will
just be overwritten on the next update.  We successfully deal with
this with the generated files, I see no reasons why we couldn't do the
same with ELPA packages.