feature: Dependency consistency of init()?

[oblitum]

Did you check the docs?

• I have read all the lazy docs

Is your feature request related to a problem? Please describe.

I have a plugin A whose dependencies is plugin B. In A's init() code, I wish I could rely on B to have been fully loaded.

Why?

Because B is a dependencies, so one may expect that, given B is a dependency of A, then one may write code that relies on B's config() inside A's init(), for example. A's init() depends on B ('s init()/source/load/config()).

Describe the solution you'd like

init() might be a code that runs just before a plugin is loaded, after all its deps have been fully loaded (which includes their init()/sourcing/loading/config()).

Notice that I'm just considering simple plugin relations without thinking about circular deps.

Describe alternatives you've considered

None. I'm still struggling how I'd circumvent this in an alternative way with a plugin dep I have in my setup.

Additional context

No response

[oblitum]

If not doable, then possibly a clarification doc over init()'s limitation when involving deps might be good to have. It seems there's init()->init() order consistency, but not config()->init() order consistency, which should be clarified.

[folke]

init() is always called during startup, before even loading start plugins. That's not supposed to contain code that depends on any plugin. So I'm not sure what you're asking here. Can you give a specific example of what two plugins? Code?

[oblitum]

My code is a bit involved on this to extract it out, but I can explain. I have a colorscheme plugin B. In B's config() I apply the :colorscheme, and then I patch some highlights. This highlighting patchset is expected to be relied by another plugin, before it's loaded. I put B as a dependency of this (A) plugin, but that won't help. I put A to load on ColorScheme event, but that won't help either, because A depends on the dynamically patched colorscheme, not the original one.

This is one situation that involves colorschemes, but the general case doesn't have to.

[oblitum]

init() is always called during startup, before even loading start plugins.

That implicitly already explains "there's init()->init() order consistency, but not config()->init() order consistency".

So, there's some doc already on this, it's just not blatantly obvious.

I still though, wonder whether this could be a doable feature, to change from "always called during startup, before even loading start plugins" to "always called just before the associated plugin loads".

[folke]

I still don't understand it, however init() is not the place to use loaded plugins. You shuld do whatever you do in plugin A's config() method

[oblitum]

I can't do it in plugin A's config() method, because the patchset from B's config() is relied by A's loading, ran before its config().

[max397574]

ig it should be possible to do it in the config of plugin B and then load the plugin in the init of plugin A

[folke]

then you have some sort of circular dependency. not possible

[oblitum]

I don't see how it's circular, it's just that initialization of A depends on B loading process to have been finished. One can easily expect that from a dependency. The current state of things is that isn't the case, initialization of A can only rely partially on B loading process (specifically, just its init(), not its sourcing/loading/config()).

[folke]

A I said before, init() is called during startup. BEFORE plugins are loaded.

[folke]

init() has nothing to do with dependencies.

[oblitum]

And I know what it is now and I have answered on that already here (#283 (comment)). I'll cease my case as I can notice you're getting stressed.

[oblitum]

Just an addition pertaining this topic that I forgot to make it clearer. A loading order limitation not associated with init(), but just dependency and config() functions.

When one sets A depending on B, they may expect to rely on B's config() to have ran before A loads (A depends on B, so B loads before A, hence one might expect B's config() runs before A loads). As far as I've tested, when A loads, anything done in B's config() isn't in place yet.

I discussed it already, but wasn't explicit as I came here focused on covering init().