Introduced runtime dependency: use-package-verbose

[PhilHudson]

See issues #13 and #17 -- it's happened again, culprit this time is use-package-verbose. Effect is that you have to (require use-package) at runtime or you get a void-variable error. As before, the fix will be to ensure the variable (user option) is eval'ed at code-planting time rather than at runtime.

[npostavs]

Introduced by #96.

[jwiegley]

@tarsius Can you address this?

[tarsius]

Effect is that you have to (require use-package) at runtime or you get a void-variable error.

That seems reasonable to me. I don't really understand why it's desirable to use use-package without requiring it at runtime - can you show me the code?

[PhilHudson]

Jonas Bernoulli notifications@github.com writes:

Effect is that you have to (require use-package) at runtime or you get a
void-variable error.

That's seems reasonable to me. I don't really understand why it's desirable to
use use-package without requiring it at runtime - can you show me the code?

Isn't that the whole point of implementing use-package as a compiler
macro: that you don't have to load it at runtime?

Not saying that's got to be the way it works, but if it is not a major
design goal, then there are downsides to the macro thing that might mean
it was better to use "ordinary" functions instead. I believe that's one
of the standard "prefer x over y" things of Lisp programming: don't use
a macro where a function will do.

Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63

[tarsius]

Again:

can you show me the code?

I suppose something like this

;;; init.el -- my init file

(add-to-list 'load-path "/path/to/use-package")
(eval-when-compile (require 'use-package))

(use-package foo :init (do stuff))

?

[tarsius]

Isn't that the whole point of implementing use-package as a compiler macro: that you don't have to load it at runtime?

Well I suppose you could look at it that way, then again isn't the whole point of having a variable that changing its value actually has an effect?

[tarsius]

Or in other words:

Isn't that the whole point of implementing use-package as a compiler macro: that you don't have to load it at runtime?

So? That doesn't mean that the expansion cannot rely on global variables defined in the same package as the macro. You just have to load the library at runtime too so that the variable is defined - that doesn't result in the macro not being expanded until runtime.

[PhilHudson]

Jonas Bernoulli notifications@github.com writes:

You
just have to load the library

Which is exactly the thing one does not want or expect to have to do.
Avoiding loading yet another package is precisely the point -- the only
point -- of implementing use-package as a compiler macro rather than as
a function, unless I'm missing something.

This problem has been addressed and fixed without controversy the
previous two occasions it has arisen. I don't understand why it's
controversial now.

Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63

[tarsius]

Avoiding loading yet another package is precisely the point -- the only point -- of implementing use-package as a compiler macro rather than as a function, unless I'm missing something.

Certainly not. One reason for using a macro is that the expansion can be done at, well, macro expansion time which gives a minimal performance increase. The main reason is that use-package provides syntactic sugar - if a function were used then many things would have to be quoted inside a call to use-package which currently don't have to be quoted, making it very ugly.

Also that's a mischaracterization, what happens is that one small package is loaded in order to avoid having to load all those other, potentially huge, packages upfront.

This problem has been addressed and fixed without controversy the previous two occasions it has arisen.

That's because nobody realized the consequence of your supposed fix: it results in customization to use-package-minimum-reported-time not having any effect, and it is a customizable option not a constant. You are simply ignoring that.

I don't understand why it's controversial now.

That's because this time around someone noted what the consequences of what you are proposing would be.

If you really really want to avoid having to load use-package at runtime, to avoid a ~ 0.029s (as timed on my machine) increase in startup time, then all you have to do is to add the following before the first use of the use-package macro.

(setq use-package-verbose nil)

or

(setq use-package-verbose t use-package-minimum-reported-time 0.01)

[PhilHudson]

Jonas Bernoulli notifications@github.com writes:

OK, I understand and accept your reasoning. That all seems perfectly
reasonable and true. I would then ask only that the (excellent)
documentation make clear that there is a runtime dependency, and that
there should be, and that this is a Good Thing, in case anyone else gets
the idea that I had. Fair? I can even do the edit if you want.

Thanks for taking the trouble to engage with me on this. I hope I
haven't annoyed you excessively. I remain hugely impressed with
use-package and grateful for it, and I hope I can be more helpful with
it in future.

Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63

[jwiegley]

I personally would prefer if use-package were not necessary at runtime, unless you wanted to autoload it for commands like describe-personal-keybindings. But it shouldn't need to be loaded just to load your Emacs.

[tarsius]

Actually we can have both using (or (bound-and-true-p VAR) DEFAULT). I'll create a patch.

[PhilHudson]

Jonas Bernoulli notifications@github.com writes:

Actually we can have both using (or (bound-and-true-p VAR) DEFAULT). I'll create
a patch.

Best of both worlds. A happy result, since the defaults seem sensible
and reasonable. Thanks, John and Jonas. Now I feel like raising my issue
was a useful contribution again, just when I'd come round to thinking it
was a waste of everyone's time. I now understand better what's involved;
as Jonas pointed out, I was ignoring the benefit of runtime user
options. I now also understand that the stakes are pretty small in terms
of performance.

Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63