Re: using use-package

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, lots of use-package is designed to work around flaws in packages.

Hi Stefan,

use-package was designed to offer sane and fast Emacs configurations. I did
not think of other packages as being flawed when I wrote it; I simply asked
myself how I wanted Emacs to behave when configuring packages.

For example, I can say ":disabled t" and everything about a package will be
dropped from my configuration. It won't be on my load-path, or available as an
autoload, nothing. Nor do I have to delete the package, or move it out of the
way, for this exclusion to happen: the decision is based entirely on my
use-package configuration.

And because of the modularity in 2.0 (i.e., keywords and related support can
be added or dropped as desired), it's not fixed in the design space. If
inclusion into core meant moving :load-path support to an ELPA add-on, that's
entirely possible.

> E.g. the :load-path thingy should never be necessary since the package's own
> autoloads should already take care of that.

I happen to prefer :load-path, since relying on Emacs' automated discovery
takes longer than loading my entire init.el now. I have tons of Emacs software
in my .emacs.d, and only use a fraction of it on any given system. One thing
use-package does is to confine load-time configuration to just those packages
I'm using for the machine I'm starting Emacs on, even though I've cloned the
same set of packages everywhere.

> IOW, in many cases, it would be better for people to report the problem as a
> bug rather than to reach for use-package.

The idea that use-package will never make it into core because "package
authors should do things a better way" strikes me as a very odd argument.
use-package lets me write modular code to solve every configuration problem I
run into; am I really supposed to not do this, because things should ideally
be better than they are? That's a bit like saying we shouldn't have locks on
our doors, because it downplays a deeper issue: that we should convince people
not to steal.

John

p.s. Side note to others: req-package does not supercede use-package. In fact,
     use-package's design post-2.0 could easily support req-package's
     functionality as an add-on. req-package is a pre-2.0 effort to integrate
     a core design change.