use-package icon indicating copy to clipboard operation
use-package copied to clipboard

Document nesting use-package declarations

Open phoenixanimations opened this issue 6 years ago • 7 comments

Example setup: test-01.el:

(message "test-01")
(provide 'test-01)

test-02.el:

(message "test-02")
(provide 'test-02)

test-combine.el:

(use-package test-02
  :after test-01
  :demand t
  :config
  (message "Config: test-02"))

(use-package test-01
  :demand t
  :config
  (message "Config: test-01"))

(provide 'test-combine)

So if you evaluate test-combine the result will be:

test-01
test-02
Config: test-02
Config: test-01

Was wondering if this was intended. Not a big issue as one solution is to just combine the last code into one use-package, or just order it properly. I'm using use-package-20180715.1801.

phoenixanimations avatar Aug 06 '18 19:08 phoenixanimations

Any updates on this? Exact same issue

cyruseuros avatar Jun 04 '19 06:06 cyruseuros

I can confirm the behavior, but I'm not sure how to solve it without needlessly increasing the complexity of use-package. For example, I think we would need to step relying on eval-after-load directly.

I'm not sure that extra complexity is worth it to cover such a specific use case. Asking users to order declarations correctly in some cases therefore looks like the better solution to me.

I'm therefore inclined to close this as wontfix, and I'm tentatively marking it as such.

skangas avatar Dec 03 '22 17:12 skangas

Perfectly valid. Perhaps just mention in the :config section of the doc, that order can still matter? If you do

(use-package test-01
  :demand t
  :config
  (message "Config: test-01"))

(use-package test-02
  :after test-01
  :demand t
  :config
  (message "Config: test-02"))

The expected (imo) output is correct:

test-01
Config: test-01
test-02
Config: test-02

If you think this is just too much of an edge case to mention I understand. Also just wanted to say thank you for this package!

phoenixanimations avatar Dec 03 '22 21:12 phoenixanimations

Perfectly valid. Perhaps just mention in the :config section of the doc, that order can still matter? [...] If you think this is just too much of an edge case to mention I understand.

Thanks for the suggestion. I will look into it to see what can be done.

Also just wanted to say thank you for this package!

All praise should go to @jwiegley, I'm just a Johnny-come-lately with the power to close issues. ;-)

skangas avatar Dec 03 '22 22:12 skangas

If you really need the strict ordered behavior for both init and config you might be in a situation where you might want to consider nesting. I use this pattern for packages that adds functionality to a "parent" package. It is way easier to see how things will load doing this instead of using :after for simple situations.

  :demand t
  :config
  (message "Config: test-01")
  (use-package test-02
    :after test-01
    :demand t
    :config
    (message "Config: test-02")))

(provide 'test-combine)
test-01
Config: test-01
test-02
Config: test-02

thomasf avatar Dec 04 '22 08:12 thomasf

If you really need the strict ordered behavior for both init and config you might be in a situation where you might want to consider nesting. I use this pattern for packages that adds functionality to a "parent" package. It is way easier to see how things will load doing this instead of using :after for simple situations.

Good point. I think we already have such an example in the documentation (see the one involving color-moccur). Perhaps we should even add a section on nesting use-package declarations.

@jwiegley Any thoughts about this?

skangas avatar Dec 08 '22 04:12 skangas

Part of the problem here is that :demand t means "load it when you see it". :after should have not have much effect in that case. So I think that the suggestion of nesting to fully disambiguate is a good idea, and it's something that I also do myself in several places.

jwiegley avatar Dec 09 '22 01:12 jwiegley