RE: ELPA and EmacsWiki Updates

[Drew Adams]

> >> The auto-installer adds a line to your .emacs.  When Emacs starts,
> >> package.el will do a dependency check and activate whatever packages
> >> it can.  (So, e.g., you can change Emacs versions and things mostly
> >> still work.)
>
> Drew> Ouch! I don't want to tell you what to do or not do, but I don't
> Drew> much like the idea of something (even something I initiate)
> Drew> mucking with my .emacs.  Anyway, that's another story, and I'm
> Drew> sure you have good reasons for doing it the way you do.
>
> Yeah.  The goal of the auto-installer was to make it dead simple to
> start using ELPA.  It is easy not to do this -- just don't run it :-).
> You can still use ELPA if you install package.el by hand and edit your
> .emacs, or whatever, yourself.

But that means that a user must know how to do that manual tinkering. A
novice will just choose the automatic behavior that does lots of stuff
invisibly. That's helpful (s?he normally won't care about those details,
presumably), but what to do when something goes wrong (of different from
what was expected)? The problem is that lack of knowledge can make things
easier when things are going as expected, and it can make things much harder
when they are not.

It's a classic help-the-user bind. To really help the user, it is important
to go beyond a monolithic, totally automatic, push-button approach. To
really help the user, tools need to also deal with trouble-shooting,
preferences, and so on. Too often, there are only two widely separated
levels (choices): (1) totally push-button: you push the button and
relinquish all control from then on, or (2) you are completely on your own,
from scratch. For #2, there is too often little doc etc., and the attitude
of developers is that if you choose #2, then you should be able to figure
things out on your own. What's really needed much of the time is a way to
move smoothly along the continuum between #1 and #2.

Emacs, in general, is helpful when something goes wrong - you can easily and
interactively poke around to understand and learn about what's happening.
This is mainly because much of it is implemented in Lisp and because of the
integrated help system.

> Basically I thought it would be fun and worthwhile to make it so
> people could be running package.el in a few seconds without needing to
> know anything... since after all one of my goals for ELPA is to make
> it possible for folks who aren't emacs lisp wizards to run stuff --
> not to mention removing the drudgery for those of us who can do it,
> but would just rather not :-)

OK, but do you need to modify a user's .emacs to do that? Couldn't you use
Customize? That would limit any modification of a user's .emacs to the
standard, easily recognized, Customize section. And if the user has a
`custom-file', then it would appear there instead. (FWIW, I always recommend
that users have a `custom-file', and keep their .emacs for their own code.)

IOW, can't you save the data you need without changing a user's .emacs in a
non-standard way?

> >> Activation means modifying load-path and evaluating the autoloads.  If
> >> the package contains a 'dir' file, package.el also modifies the info
> >> path.
>
> Drew> Ouch again!
>
> Drew> I sure hope there is a foolproof way to uninstall - a way that
> Drew> backs out all of the automatic changes that you make to a user's
> Drew> environment. Been bit by this kind of "helper" tool too much to
> Drew> welcome it blindly.
>
> The load-path stuff is all done dynamically, when package-initialize
> is called at startup.  To remove a package you can just "rm -rf" the
> directory in ~/.emacs.d/elpa/.

And edit your .emacs to remove the changes package.el made to it, including
to the load-path? Anything else? ;-)

> Eventually I'll write package deletion support for the package menu
> mode.  I've put it off.

I'd think that would be the first thing to write ;-). Making it easy for
users to install some new software is great, but it is even more important
to make it easy for them to get back to exactly the way things were before
they tried to install it. This is a lesson that Windows users learned on Day
2 - the hard way, unfortunately.

I don't know. I'm all in favor of making things easy for users. But in
practice that too often means imposing a bunch of stuff that a user might
not really want (if fully aware) and that s?he finds it difficult to get rid
off or bypass thereafter. (I'm not saying that this is the case for
package.el.) I'm in favor of conscious opt-in as opposed to opt-out, and
when I uninstall something I want it to be totally gone - (1) no vestigial
files, directories, registry entries (Windows), or text added to any of my
files, and (2) everything that was removed to install or run the program is
put back in place.

Again, I don't say there is any particular problem with package.el - I'm
speaking generally. I'm leary of the push-button getting-started approach.
It makes things easy, but too often installing is easy and removing is not
so easy.

There's a tradeoff when a program does things on behalf of a user; it's
important to somehow let users still control things if they want to, in
particular, to let them easily opt out of some of the automatically imposed
behavior. And to let them (and help them) regain control later if they
initially chose the automatic route. The tradeoff is that making things easy
often means making details invisible - doing things behind the user's back.
That's convenient, but it can have its disadvantages, as we all know.

Here's the thing: As long as an Emacs tool or library does _not_ hold you by
the hand, it can expect you to be ready and able to tackle Emacs Lisp to
some extent. If, however, it takes you by the hand initially and purports to
do some heavy lifting on your behalf to get you started, it should also
accept the responsibility of staying by your side throughout the journey.
IOW, if a tool gives you a push-button to get started, it should also
provide help to you beyond that point. Anything less is unfair and
unhelpful.

> Unloading something after Emacs has started and package.el has
> initialized can't really work.  Emacs just isn't good at this kind of
> thing.  There's unload-feature these days, but even that won't undo
> the additions of autoloads and stuff.  So, if you want to delete
> something you have to restart Emacs.  That sucks from a UI point of
> view.

It's not a big problem for a user to restart Emacs. If that takes care of
removing everything that was added and reverts all changes that installing
effected, then there is no problem.

> I keep going back and forth on the question of package activation.
> Right now, if a package is installed, package.el tries to activate it
> at startup.  But, we could store a preference so you can choose not to
> have some activated.

I have lots of Emacs stuff installed (available) that I don't start up
automatically. I have lots of stuff that I don't even autoload - I just want
it to be there (in my load-path) so I can use it when I want.

I would think that installing and activating (depending on what is meant by
the latter) would be two different choices for a user to make. Why couple
them?

> One way this would be nice is if package.el was really widely used,
> including to install 3rd party elisp in a distro.  Distros, in my
> view, have a problem where for most users they want to enable
> autoloads for all additional packages, but some power users want to
> turn off certain things.  In this situation package.el would allow
> deactivating the uninteresting things.

Yes, it would be good if package.el let you select stuff that you wanted to
activate.

Similarly, I think that a simple GUI for managing one's load-path might be
useful. I think that Emacs users need to be aware of their load-path. I
don't think it can be hidden from them without courting danger. But a good
interface for viewing and managing the load-path and library dependencies
could perhaps be developed.

IIUC, package.el helps you manage package conflicts - for example, multiple
versions of the same package. That feature could perhaps be integrated with
a general load-path browser that would let you query, auto-detect, and
manage other possible conflicts (whether from "packages" or anything else).

> Anyway I'm not sure whether this is worth implementing.  On the minus
> side it adds more complexity and UI.

One Tromey can only do so much! We are all grateful for your contributions.
Even though package.el might not be a good fit for some of my own code, as
you pointed out, I recognize that it can be helpful.

Sorry for the generalizations, most of which probably aren't relevant to
package.el. Something must have pushed my button ;-).