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

[Eli Zaretskii <eliz@gnu.org>]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: a.s@realize.ch,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 09 Oct 2016 21:38:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> 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?
> 
> Without installation -- that is, as part of core emacs.

What do you mean by "installation" in this case?  Copying each file to
its place, as opposed to just replicating the same directory
structure?  Or do you mean something else?

> >> 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?
> 
> Why not? It's a convienient way of building packages.

If that convenience comes at a price of making our directory structure
harder to work with, it's more like INconvenience.

> > 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
> 
> All of these, I think.

Each one could have a separate solution.  For example, the first one
could be done with Git commands, bypassing package.el entirely, or
with Git commands followed by something that package.el does to
populate the right directories.

> > 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 enables the convienience of taking a directory containing a package
> from ELPA and putting it within the Emacs build unchanged. This seems
> clean and simple. It should also enable "git submodule/subtree" type
> options.

See above: it could be easy to do, but be a nuisance in the long run.
So it is IMO incorrect to consider only the short-term convenience of
putting together the necessary machinery, we need to consider the
long-term convenience as well, if not first of all.

> >> 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.
> 
> Downloading is copying right?

That price cannot be avoided, since ELPA is a different repository.
Right?

> >> 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?
> 
> There are generated .el files in Emacs, and there are specific cases
> where this is necessary, but it's not a great thing. Mostly, I think,
> .el files should be source code. At the moment, it's only a few files.
> Making this more common seems bad.

I disagree.  I see no reason to consider generated files "bad".  And
there's no fundamental difference between generating them by C or Lisp
programs and "generating" them by using Git commands.

> >> 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.
> 
> Yep, which is bad, if you didn't intend this to happen.

We deal with this "badness" every day.  So I think this is a downside
that is very minor and can be disregarded when more serious issues are
at hand.