include a specific "load" hook for Xontrib ?

[Carreau]

I'm running into the question of whether Xontribs should do all their shenigan at import time, or not. My reasoning is that in the current one I'm developing, I need to have access to __xonsh_shell__, which is fine if I manually load the xontrib.

Among other I want to bind shortcuts, so I cannot use a lazy accessor, or I would have.

Though, if I register the xontrib to be loaded at startup, it will be loaded during the initialisation of __xonsh_shell__ = Shell(..) leading to __xonsh_shell__ not being in built-in yet, and me getting a name error.

May I suggest to standardise with the convention that if a xontrib module define a function called xontrib_init(parameters, to , define) this get called at a well-known step in the initialisation process; possible in a state which will be identical as doing xontrib load whatever ?

I would suggest not to pass any arguments for now, but to recommend implementation to allow *args, **kwargs parameters.

---

Also in general I don't like import having side effects., and I would prefer an init method that get passed a reference to a global namespace instead of implicitly accessing __xonsh_*_; but that's a personal preference.

Thoughts ?

[AstraLuma]

I thought about rolling this as an event, but the problem is that xontribs loaded latter still need it to be called (behaving more like a future than an event).

Are the any documents that would describe the initialization process?

[Carreau]

I thought about rolling this as an event, but the problem is that xontribs loaded latter still need it to be called (behaving more like a future than an event).

Yeah, I was unsure of that either. I also want to modify this PR to actually call the equivalent of xontrib load instead of having the logic twice. I think that would be the most reasonable.

[scopatz]

Yeah, as mentioned in the PR, I think something that is more amenable to an event system is preferable.

[AstraLuma]

So the solution stubbed out in #1501 is that load hooks are part of the event subsystem as the LoadEvent species.

On fire, LoadEvent needs to call each registered handler. On subsequent calls, fire() will no-op. After the event fires, any handler that is registered is called immediately. (Note that any handlers registered while fire() is running must still be called.)

An implementation is like 80~90% there, but I wanted to make sure there was an opportunity to discuss the semantics.

[AstraLuma]

Real use case: xontrib-avox needs to take action pre-first-prompt. (Or post-xonshrc?) This is blocking a real fix for astronouth7303/xontrib-avox#3.

[AstraLuma]

Also, could load events be the solution prompt-toolkit hooking?

[scopatz]

Probably :)

[scopatz]

I think this is closeable