Re: req-package

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Right now, `use-package' is nothing more, but a convenient way to
> structure configurations of packages, especially in terms of autoloads
> and deferring. Yes, right now it's more cosmetics and sugar, rather
> than something that one cannot live without.

Sure.  The autoloads part is mostly redundant for ELPA packages, but the
structuring part is indeed nice.  And convenience is something we all
appreciate.

> In this thread, however, we want to go deeper and discuss package
> "configuration-time" dependencies (which are not covered by
> `use-package' by default),

Exactly.

> The biggest issue, that is not solved anywhere (neither vanilla Emacs
> nor `use-package' provide facilities for this) out of the box, is the
> one that I described two posts earlier with the example on `a' and
> `b'.  Did you understand the issue?

I must have missed it.
[...going back in the thread...]
OK, found it.  But no, I don't understand the issue.  More specifically,
I understand your hypothetical example and the problem it introduces,
but I'm having a hard time imagining when that happens in practice.

We have plenty of concrete problems that I prefer not to worry too much
about the hypothetical ones (except the ones I like, of course ;-)
[ This said, sometimes the hypothetical problems are helpful to see the
  problem in its full generality and thus find a better solution.  ]

More specifically, Elisp being Turing complete (and side-effectingly
dirty and all), I know for a fact that I will always be able to come up
with some example where any neat solution won't be able to express the
specific configuration I need.

** Random thought 1

BTW, part of the problem with a solution like use-package is also that
it hides what it does.  And in some cases you need to know how it does
its job in order to be able to tweak it correctly.
E.g. depending on how the ":config" thingy (which IIUC runs after the
package is loaded) is implemented, a (with-eval-after-load <pkg> <code>)
might end up running either before or after use-package's :config code.

So, we have the usual problem (recently mentioned in the context of
ELPA), that when it works, it's great, but when it doesn't it makes
things harder because you have to look under the cover to see what happens.

** Random thought 2

The design of something like use-package necessary has to start with
the design of a convention that is simple enough to be attractive yet
powerful enough to cover the vast majority of existing cases, *and*
where most of the remaining cases can be accommodated by the package
author (i.e. the packages need to be tweaked to make configuration
easier).

To take the example of Customize, the design is something like:

   We only handle global variables that are only modified via Customize

This covers many cases, but far from all.  And it's inconvenient to
accommodate this limitation by adding more global variables
(e.g. splitting `foobar-hook' into two, one that is fully under the
control of Customize and another that can be modified by Elisp packages;
or adding `foo-bar-enable' to control whether the `bar' major mode
should enable the `foo' minor mode).


        Stefan