Lazy loading dependencies

[redbeardymcgee]

I've added Overseer to my setup, and it auto-detects telescope as a picker for menus. However, it doesn't know telescope exists until I trigger telescope in some other way first, so I get a fallback picker built in native vim.ui.select I think. This UX is broken (might be skill issue), but I don't care to find out what breaks it.

Instead, I'd like to ensure that telescope is loaded before overseer. Is this something I should do in overseer's spec with before to require("telescope"), or in telescope's spec by adding it to on_require? Both seem like valid options, but I'm curious whether one should be considered more idiomatic than the other. Other dependencies appear to be mostly configured as eagerly loaded startup plugins, such as plenary.nvim.

[BirdeeHub]

Assuming you are using lze for lazy loading, you would set dep_of to load before the load hook, of the other spec, which by default is what calls packadd, loading the plugin.

dep_of will load the spec it is on after that other plugins before hook and before its load hook.

There is also on_plugin to load after the load hook but before the after hook.

So in the telescope spec you would put dep_of = { "theotherone" }

If the other thing does indeed require telescope however, instead of dep_of you could put on_require = "telescope" and lze will load the spec in which that is set whenever some submodule of telescope is required and fails to load (via a custom package.loaders entry it adds at startup)

[BirdeeHub]

And dependencies downloaded indirectly via the .dependencies or .passthru.dependencies key on plugins are indeed configured to be present at startup, although they dont usually have anything that they do at startup, they are usually things which others call require on when needed. Those come from the nixpkgs definitions for the plugins, and nixCats handles those as the builtin wrappers do.

You could use .overrideAttrs on the plugin derivation and remove them if you wish, giving you full control over where it goes, although, for example with plenary, it would be a wasted effort as it doesnt do anything until you require it anyway

[redbeardymcgee]

I'm not sure how I forgot about dep_of. Is there any reason why you chose to have dependencies declare their dependents, instead of the other way around?

[BirdeeHub]

Because the specs control how THAT item loads, not how other items load.

If you want this plugin to load before another one you tell it so.