But, if we’re using use-package to also manage installing the packages for us (:ensure t), then why shouldn’t it know about the autoloads already and automagically imply a :defer t by default?

Package installation and activation are two seperate concerns. :ensure ensures the package is isntalled if it isn’t already. Users might want to ensure a package is installed and prefer it to be immediately required.

So, by default, we have to remember to either add :defer t or we have to remember that setting our own hooks, bindings, or commands will create autoloads for us.

I feel like you’re misunderstanding what autoloads do. Hooks do not autoload anything. The :commands use-package keyword does autolaod commands. This is useful when a package author has not provided the autoload cookie in the package for a command, or when you wish to forgo loading all of the autoloads.

I know that you can configure use-package to behave as though :defer t is set by default, but that’s just broken for packages that don’t have any autoloads.

How is it broken? There are other ways to load a package. Namely, require.

It feels like maybe use-package is doing too many things.

It only does what you tell it to do via user options and declarations.`

but that kind of sucks because there’s no reason to load magit before I actually want to use it for anything. So, what we can do instead is to implement the project.el integration ourselves

Or (use-package project :ensure nil :defer t :config (require magit)) There are multiple ways to set this sort of thing up and use-package (which should have been named use-feature) can be used to configure built-in features.

Either I’m a little dim or the tooling here is hard to use correctly.

Third option: You haven’t taken the time to digest the use-package manual and/or expand the macro to see what it’s doing. It’s a DSL. You have to learn it to use it effectively.

Am I the only one?

You must be. Otherwise someone would’ve written “use-package alternatives”, which has an almost searchable ring to it.

Ultimately, organization comes down to the user. Tools like use-package make it easier, but they do not guarantee it.

(imo) you’re using it wrong, I made everything defer by default then rely on autoloads and/or :bind/:commands with light use of :after . 99% of things are lazy loaded after an hour or so of work on a > 1000 line .emacs . It’s not ideal and I should probably turn most of :commands into patches upstream for auto loads but I am lazy.

With that out of the way…

Your life story wasn’t in the way until you put it there.

Your question could be condensed to “use-package is extra bureaucracy when you need to do something non-trivial, e.g., reconciling two packages’ config.”

I found use-package impenetrable as a noob. It only started making sense after I learned the subtleties of minor modes, autoloads, keymaps, custom variables, etc., at which point use-package became superfluous macro alchemy. Judicious use of `eval-after-load’ is all you need and a lot less wtf.

Since, project.el is built-in to Emacs, it’s probably most reasonable to do that config in the magit use-package form

A key tip which took me a while to internalize: you can create use-package stanzas for built-ins. I do so all the time. E.g.:

;;;;; emacs server 
(use-package server
  :config
  (unless (server-running-p)
    (message "Starting Emacs server...")
    (setq server-client-instructions nil)
    (server-start)))

People seem to be missing the point that no conceivable package loading tool — use-package, general, straight, by-hand gnarly lisp using eval-after-load, etc., etc. — will solve the original problem as stated. You want a binding to appear, tying project to magit. That binding is specified at the top level in one of magit’s many lisp files. You want this binding to appear without loading magit. There is no approach which will accomplish this, other than excerpting that binding yourself, as you’ve done in the “clever/hacky” solution (though I’d put it in the project :config stanza for better organization).

The way simple extension loading works in other applications in my experience is “fully load all configured extensions at startup”. This solves many problem (including this one), but is slow. You have the option to defer loading and much more with Emacs; the price you pay is complexity and the need to understand how the pieces fit together.

Personally I don’t think use-package is all that useful. Without it, you need to know what should to go inside a with-eval-after-load block (basically, define-key) and what doesn’t. But then again, with use-package I guess you need to decide what is a :config and what is a :init or whatever.

The :ensure keyword is very useful. There should be an equivalent function in package.el but that’s missing AFAIK.

You are doing it completely wrong

I use :custom a LOT. Config is so clean and short compare to default setup.

(use-package magit
  :ensure t
  :defer t
  :functions magit-status
  :custom-face
  (magit-diff-added ((t (:background "dark slate gray" :foreground "chocolate"))))
  (magit-diff-added-highlight ((t (:background "dark olive green" :foreground "gold"))))
  (magit-diff-removed ((t (:background "red" :foreground "#ffdddd"))))
  (magit-diff-removed-highlight ((t (:background "dark red" :foreground "navajo white"))))
  :custom
  (magit-diff-refine-hunk                'all)
  (magit-display-buffer-function         'magit-display-buffer-fullframe-status-v1)
  (magit-ediff-dwim-show-on-hunks        t)
  (magit-log-arguments                   '("--graph" "--color" "--decorate" "--show-signature" "--follow" "-n256"))
  (magit-log-margin-show-committer-date  t)
  (magit-log-remove-graph-args           '("--follow" "--grep" "-G" "-S" "-L"))
  (magit-todos-insert-after              '(bottom))
  :bind(
  ("C-x C-z" . magit-status)
  :map evil-normal-state-map
  ("gs"  . magit-status)
  )
)

I think you are right, at least for problems of configuring multiple packages together. I think there may be another useful way to organize configs, but I haven’t come up with anything yet. For now use-package is pretty optimal.

I don’t use use-package, but I’ve seen a lot of questions from users who do use it but don’t understand how to use it, or what it’s going to expand to, or what the things that it expands to actually do. My conclusion has been that for some users it introduces as many problems as it solves. I think those users would be better off if they learned how to manage their config without it first, and only considered use-package after understanding the more fundamental building blocks upon which it is built.

It’s certainly not something you need to use, in any case. It’s clearly an invaluable system to many users, but if you don’t get along with it, don’t use it.

This isn’t so much a problem with use-package as it is the primitives (autoload and with-eval-after-load) and the way Emacs manages load order with load-history. I don’t know that you can write a better macro to handle composite package configurations under these constraints. I also haven’t tried to, so maybe there is.

An actually declarative system will need something like a fixed point evaluator, and be much more complicated than use-package internally.

Practically speaking, the only solution right now is (i) proactive measures by package authors to shove all the bits meant for integration into separate file(s) and provide separate features, and (ii) knowledge of this organization on the part of the user.

Even this can be too much, magit-extras (which contains magit-project-status) is 900 lines, most of which you don’t need.

One of the things I don’t like about it is the :custom part, if I want to change a variable I’ll have to re-evaluate the whole use-package form.

> Maybe it was actually more correct in the old days to separate the installation, configuration, and actual loading of packages, rather than trying to do all three in one API.

​

IMO, yes, this separation of concerns is a good ideia – or at least the ‘installation’ phase from the others.

In my config, I use `package-selected-packages` and `(package-install-selected-packages)` rather than depending on `use-package` installation facilities. Code.

I think your problems are due to not understanding how Emacs works under the hood. To me, the only problem with use-package is that it hides those details and makes people learn a DSL that use-package is, instead of learning simpler mechanisms of with-eval-after-load and hooks which are used to implement the functionality of use-package under the hood. In past years I have seen many questions here on Reddit and on SX related to use-package because people don’t understand Emacs under the hood. But that is about it; I see no other drawbacks than that.

Personally, I have stopped using use-package after about 2 ~ 3 years ago. Been using it for a few years before that. The reason why I abandoned it was actually because I wanted to learn how such a thing was implemented and how Emacs worked under the hood. Another reason was that use-package was not included in Emacs back in time. However, I am not going back to use-package, just because it got included. Partially I am too lazy to rework my setup again, and partially I personally don’t need it.

To be clear, I don’t agree that use-package is wrong about anything or poorly written or anything like that. On the contrary, use-package has its very good points. One of them is that everything related to a single package is condensed into one place. At least configurations that are built around the use-package tend to be well structured. That part itself is a very good reason to use use-package, unless you have the very good discipline or come up with a system to organize your init file.

You are right, and I never use use-package

I have a tangential observation to contribute. It seems like `use-package` is the way to configure settings, yet customize-group, customize-variable make no use of it. There is a mismatch, others see that too?