New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nesting use-package declarations vs using :after #453
Comments
As a general tip for understanding
I imagine only in specific, simple cases, e.g. when the Here are two sample expansions to illustrate the subtle differences in semantics (note that I have simplified the expanded code for clarity): ;; 1. Using :after
(use-package flycheck-popup
:after flycheck
:config
(ignore "Loaded 'flycheck-popup"))
;; Becomes:
(progn
(with-eval-after-load 'flycheck
(require 'flycheck-popup nil t))
(with-eval-after-load 'flycheck-popup
(ignore "Loaded 'flycheck-popup")))
;; 2. Nested
(use-package flycheck
:defer
:config
(ignore "Loaded 'flycheck")
(use-package flycheck-popup
:defer
:config
(ignore "Loaded 'flycheck-popup")))
;; Becomes:
(progn
(with-eval-after-load 'flycheck
(ignore "Loaded 'flycheck")
(with-eval-after-load 'flycheck-popup
(ignore "Loaded 'flycheck-popup")))) In the former case, anything that causes In general, I find the former approach much clearer and robust, as the I have yet to come across a sufficiently compelling reason to nest As an aside, I would be interested to know how nested |
Here is the same example with stricter semantics (no ;; 1. Using :after
(use-package flycheck-popup
:after flycheck
:config
(ignore "Loaded 'flycheck-popup"))
;; Becomes:
(progn
(with-eval-after-load 'flycheck
(require 'flycheck-popup nil t))
(with-eval-after-load 'flycheck-popup
(ignore "Loaded 'flycheck-popup")))
;; 2. Nested
(use-package flycheck
:config
(ignore "Loaded 'flycheck")
(use-package flycheck-popup
:config
(ignore "Loaded 'flycheck-popup")))
;; Becomes:
(progn
(when (require 'flycheck nil 't)
(ignore "Loaded 'flycheck")
(when (require 'flycheck-popup nil 't)
(ignore "Loaded 'flycheck-popup")))) Again there is a difference in semantics, but it's subtler than in the previous, non-strict example. In the former expansion, loading The only benefit of nesting here is that A related |
I've always used
I don't think there is anything about byte-compiling that matters for that, you can try |
@npostavs Thanks for the pointers. :) |
Hm, I've been using nested (use-package org
:config
(use-package org-recent-headings ...)
...) It seems to make sense to me to keep the org-related packages' configuration nested inside
That seems like an important benefit to me. If the package that is depended upon fails to load, packages that depend on it won't also fail to load, preventing extra noise in the form of more errors and warnings.
Hooks are good, for packages that have the appropriate ones, but using nested Thanks for the discussion. |
@basil-conto I'm unsure about the statement "flycheck-popup will not be configured unless flycheck has already been successfully loaded". What is telling you that that? Seems to me like |
I appreciate that. One downside that pops to mind is that nested
Definitely, though not all packages exhibit such a strong dependency. Error verbosity can also be a matter of preference/circumstance. For example, one might care less about silencing load errors and more about fixing the underlying cause when they arise.
I guess it's a failproof alternative to hooks for enforcing package dependencies, but I can imagine this playing less well with other initialisation features, such as the aforementioned @therockmandolinist
The syntax tree. :) Compare the sample expansions I listed: ;; 1. Using :after
(progn
(with-eval-after-load 'flycheck
(require 'flycheck-popup nil t))
(with-eval-after-load 'flycheck-popup
(ignore "Loaded 'flycheck-popup")))
;; 2. Nested
(progn
(when (require 'flycheck nil 't)
(ignore "Loaded 'flycheck")
(when (require 'flycheck-popup nil 't)
(ignore "Loaded 'flycheck-popup")))) In (1), the In (2), On a side note, I realise now that using |
Thanks for explaining it all so well @basil-conto, and all you other for asking questions. 😃 |
@sondr3 I'm glad you found this discussion helpful; I certainly did. :) @therockmandolinist
Sorry I overlooked this question last time, though I believe I have at least partially answered it already. Ultimately, the point of any of these features is to expand to their respective definitions, which may or may not align with the author's intentions. A misalignment is a bug; anything beyond that is either a feature request or a discussion on naming. :) Philosophy aside, I think we can all informally agree that (use-package dired-x
:after dired
:bind ("C-x C-j" . dired-jump))
What your question seems to be suggesting, though, is a complete suppression of dependent packages; is this really your intention? Either that or you're trying to blame a botched package installation on |
@basil-conto No need to jump to conclusions - it was simply a question based on skepticism, which you've actually addressed nicely, so thanks! |
@therockmandolinist Sorry if I sounded accusing, I was just thinking of different possibilities out loud and/or rambling. :) |
raises the error A single nested
but I don't thinkit'is as clear as multiple nested Could someone comment on the multiple nested |
Try (use-package muse
:config (progn
(use-package muse-docbook)
(use-package muse-html))) or (use-package muse
:config
(use-package muse-docbook)
(use-package muse-html)) |
I now prefer non-nested |
after un nesting the packages like is suggested jwiegley/use-package#453 (comment)
Configuring nested packages, see jwiegley/use-package#453
I'm a bit confused as to the difference between nesting declarations of use-package versus using the
:after
keyword. For example, if you were doing something like this:Would that be equivalent to having the declarations separate and using
:after flycheck
onflycheck-popup
? Or would you have to use:after
even when nesting them?The text was updated successfully, but these errors were encountered: