(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.

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.

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.

General is a package that really illuminates the tension that occurs when the user wants to integrate two packages. :after is okay for a quick solution, but for packages like general, you would end up with one ensured package implicitly depending on everything.

It’s much less bad that you end up loading everything and much worse that the use-package declaration feels anything but modular or independent, instead incorporating symbols from all over Emacs and implicitly depending on other use-package hunks.

What is still a much deeper problem in my opinion is the lack of being able to superimpose and compose configuration. This is the reason why adopting random hunks of use-package declarations is not safe and why almost no two users can easily re-use large units of configuration.

Wrong or not, it seems it’s completely unnecessary in Emacs 29 for me.
.emacs is so much cleaner now.

You have the wrong target. I don’t think you are (or should be) actually complaining about use-package, but about the setup of various cross-package “tie-in features”. So magit knows about project.el. It kindly offers to add a special command to project-switch-commands, but (quite reasonably) only after project.el is loaded, and if project-prefix-map is defined. Luckily the latter is a builtin autoload, so it’s just a matter of ensuring project is required with magit before you can use the tie-in, whenever you want that to happen.

As already pointed out, you could add (require 'project) directly in magit’s use-package :config stanza to make this tie-in happen right away after magit loads. Or, perhaps even better, identify a hook (magit has many) to do this “just in time” before you use magit in some meaningful way. If you want this tie-in to happen somehow magically without loading magit, good luck with that; it’s a literal top-level (with-eval-after-load 'project) in magit-extras.el! You only option is therefore to do what you did: boost that logic out into your config. Or how about this: (require 'magit-extras) in your (use-package project :config). That way you’re only loading a tiny part of magit when project.el is loaded.

The bottom line: how is use-package or any other config paradigm supposed to know when you’d like magit’s project.el tie-in to activate? Some people would like to have project -> magit interaction on demand the very first time they invoke the project menu in a git-controlled file. Others want that tie-in command available only if they have already been working with magit in a session. You apparently want it active and ready to go without loading either package. This is way beyond use-package’s scope. The only solution is to investigate the nature of the tie-in, and configure it yourself to work the way you want. Which is what you did ;).

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.

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.

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)
  )
)

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.

You are right, and I never use use-package

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.