RE: Future role of ELPA (was: [ELPA] tramp-theme.el)

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

> >> As a user I really don't like that a lot of functionality is now moved to
> >> ELPA. When I install a new emacs, I have to re-install also all needed
> >> packages from ELPA.

A reasonable critique, I think.

> >> It would be so much easier when all the batteries in emacs are still
> >> included.
> >
> > The future plan is to move even more things into ELPA. However, parts of
> > ELPA will be included in future Emacs tarballs, so your batteries will
> > actually be there in that future.
> >
> > So, rather than asking whether things can move back into Emacs, the better
> > question is: how should we proceed with our plan to deeply integrate ELPA,
> > so questions like this are resolved in passing. We've had some progress in
> > this direction, but there are still a few matters of process to resolve.

Exactly.  I'm glad that this user (Stefan) posed the question and made known
his use case.  It should be taken into account ("resolved in passing").

> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
> 
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
> 
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.
> 
> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
> 
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
> 
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.

Indeed.

> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.

I agree with you.  But I also agree that it is good to modularize the
Emacs code, e.g. by moving some of it to GNU ELPA.  That can help both
Emacs development and the use cases of some users.

I agree with you that a user should be able to ask Emacs about something
(e.g., a command) that has traditionally been provided with the Emacs
distribution, without having to use the package system to add it.

In a way, perhaps what is needed is a "super autoload" facility, that
is, a more sophisticated way of making use of the package system,
so that the same behavior as before a breakup into separate packages
is still available seamlessly, even if under the covers packages are
brought into play.

The key here is "under the covers": A user should not _need_ to do
anything or even to be aware that packages are being jockeyed into
place automatically to accommodate an inquiry or an on-demand use
of a feature.

A user should not be required to (consciously, manually) use the
package system at all, to interact usefully with Emacs.  A user
should be able to have everything that s?he had from Emacs
previously on disk, locally, without jumping through any hoops.

There should be no need to connect to the Internet to work with
Emacs, at least regarding the large set of commands, options, etc.
that has traditionally been distributed with Emacs.

IOW, it should be possible for a user to use Emacs without the
package system, just as easily as before.  Adding the package
system should be only a plus, not a plus and a minus.  Users should
be able to interact with Emacs in different ways, and not be obliged
to get only a tiny core by default and then have to install the
pieces they feel are missing.

At the same time, it would be good if the Emacs code were composable
from libraries in a repository such as GNU ELPA.  How these two needs
can best be composed I don't know.  But I don't think we should
be sacrificing user access to what used to be the Emacs code base on
the alter of the package system.

What is convenient for Emacs development and for some users some of
the time should not trump the ability of other users (or the same
users at other times) to interact with Emacs as they would have
before the package system.  If you need to activate a package to get
information about `forward-sexp' or whatever, then we have lost something.

That users _can_ choose not to "install" Tramp or whatever is a
good thing, no doubt.  But it is not necessarily a good thing that
users should have to manually "install" Tramp or whatever, just to
be able to talk to Emacs about it or even to make use of it.

All this is a way of saying that we might need to think some more
about how Emacs and Emacs Dev make use of the package system, a
system that, on its own, is a good thing.  It should not become
a sledgehammer that makes everything in Emacs look like a nail.