This is incorrect. The installer directly clones Elpaca. Elpaca is not hosted on any ELPA. Doing so would require an installer package to be installed by another package manager.

Ah, right. That’s obvious in hindsight, but I didn’t give it much thought.

Remember when you first setup elpaca in your init.el and you copy+pasted a big block of elisp from elpaca’s documentation? That elpaca setup code has a version-number variable that it sets. When you initialized your new Emacs instance, it installed elpaca from MELPA, but the version on MELPA is a newer version than your copy+pasted code from elpaca’s docs. The solution is to replace your copy+pasted code by copy+pasting the new code in elpaca’s docs.

As for :init, whatever you put in there you can just put outside of use-packge right?

99% of the time, yes. As far as I know there are three “lifecycle hooks”: prelude, init, config. Prelude is evaluated when the use-package form is encountered no matter what (even if it’s :disabled, etc); then init is evaluated if the package is not disabled via :requires, :disabled, :if, etc; then config is essentially the same as with-eval-after-load.

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

Yes, agreed. My contention is not with the inherent complexity of the situation. Rather, my issue is related to this last part of your paragraph,

though I’d put it in the project :config stanza for better organization

That’s the whole problem with using use-package forms for configuration! use-package is centered around a single feature at a time, whereas many configurations involve tying multiple features together. In this case, it doesn’t matter if I put the configuration in project’s use-package form or in magit’s use-package form–in either case, one of the forms will be misleading because it will seem like all of the configurations related to that package is in that form, but it won’t be true because something about it is being configured in the other package’s form.

That’s not the only thing, either. Another example is completions. I use vertico and corfu, but they tie in closely with a lot of built-in Emacs completion stuff, so I have the following settings,

(customize-set-variable 'read-extended-command-predicate #'command-completion-default-include-p)
(setq completion-category-overrides '((file (styles partial-completion))))
(setq completion-styles '(flex basic))

those settings are not part of the vertico package, but they’re being set because I’m using vertico and want it to behave a certain way. So, do they go in the vertico use-package, or do they go in an emacs or simple.el use-package, or do they just go at the top level somewhere?

The truth is that we don’t actually configure packages in isolation, which is why I feel like use-package kind of imposes a structure that appears to make sense in a lot of cases, but does NOT actually make sense in the general case.

That’s also true of the :map and :hook forms, no? They all use magical syntax sugar that is meaningless outside of the macro. Luckily, :init and :config basically just wrap their contents in a (progn) with some error handling, etc.

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.

As a software developer, if you have to understand (exactly) what is happening under the hood of an abstraction in order to use it correctly, then it’s not a good abstraction. The entire point of abstraction is to allow us to think on a higher level, and I would say that use-package fails that test because it has a ton of nuance and subtle self-interactions that requires me to more-or-less just macro-expand all of my declarations to see what they are actually doing.

The fact that so many people struggle with it gives credence to this as well. Frankly, Emacs is complex and complicated. It has lots of legacy baggage and idiosyncrasies, so I would expect people to get their with-eval-after-loads wrong or their keybinding syntaxes wrong. But, use-package seems to hurt as much as it helps.

Can you give me an example where you use :after? Isn’t it pretty tricky to use :after when also setting use-package-always-defer?

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

I find that adding my “credentials” or background sometimes helps when posting questions or discussions on Reddit. If I had posted that I found use-package’s handling of autoloading a little confusing without any context, I’m fairly sure that I would get a bunch of replies explaining how it works, rather than a discussion of whether the way it works is good.

But, basically, I agree with you that eval-after-load is about half of what I wanted from use-package–the other half being a way to declare which installable packages I want available.

I bet that folks that prefer vi to Vim

Those exist? That’s like hipster^2 (I say this as someone who can’t even type a damn email without my Vi(m) reflexes kicking in).