RE: ELPA policy

[Drew Adams <drew.adams@oracle.com>]

> > Here's a naive question regarding where you place Lisp code
> > that is distributed with Emacs (part of the tarball): Will
> > anything change for users, depending on where you happen to
> > manage the code wrt ELPA etc.?
> >
> > I'm guessing (and hoping) not, so that the distributed
> > directory structure will remain the same.  Is that correct?
> 
> That's a good point. But I'm not clear what previous state you are
> comparing to.

Previous delivery of Emacs (back to ~Day One), including its
source code, especially Lisp, under directory lisp/.  What's
unclear about that?

> There are two cases;
> 1) A package that is currently in Emacs git moves to Gnu ELPA git but
>    remains in the Emacs tarball.
> 2) A package that is currently in Gnu ELPA git stays there, and is added
>    to the Emacs tarball.
> 
> I would argue that tarball ELPA packages should be installed in some
> system level elpa directory (similar to the user's .emacs.d/elpa), not
> in the main emacs/lisp install directory.

You say you would argue that, but where's the argument?  How about
a reason?

As one user, I would prefer that all distributed Lisp code be under
lisp/.  Makes things simpler for users (who might even have existing
scripts etc. that expect this).

Is there a good reason not to keep this behavior?

I don't really care where you stick code, or how you access it, for
development purposes.  Where an Emacs distribution puts it for
_users_ should remain what it has been, IMO, if possible - somewhere
under lisp/, at least.

Why should changes in where you keep code for development affect
where users of Emacs find it?

> I don't think the history of a package should determine where it is
> installed. So in case 1), I expect the package to be in a different
> installation directory from the previous Emacs release. But it's still
> in the default load-path, so this change is transparent to the user.

`load-path' is not everything, so no, it is _not_ transparent to
users, depending on what they do and how they use Emacs (including
its source code).

Emacs should be able to present its source code to users in the
same way as in the past, I would think.  They certainly should
not be _required_ to use the package system or git or ... to
access it.

`package.el' should be a nice-to-have.  It should not become an
obligatory hoop for users to jump through.  Most users will find
it handy, just as some users might find a menu handy.  But it
should not become a necessary way to access Emacs code.

> But it's not too important; the important distinction is that tarball
> ELPA packages are _not_ in the developer Emacs workspace, so core
> code cannot accidently depend on them.

That might be important to developers, but it is not the issue I
asked about.