Temporary registration via context manager about pluggy HOT 10 OPEN

@tgoodlet sounds potentially practical, but also not something we can expose in pytest (due to lack of plugin dependency maangement)

from pluggy.

Nothing against the proposal, I'm a bit curious about the use case: the temporary plugin registration is for testing, or to be used during production?

from pluggy.

@RonnyPfannschmidt oh yeah? Is there a way we can fix that?

@nicoddemus I was thinking both. It allows a plugin creator to overload hooks temporarily. If a hook is called multiple times under different contexts it may come in handy.

One example from pysipp is only on the first hook call do you want the netplug plugin registered (it allocates random ports from the system for SIPp to use as default arguments) for the first call to pysipp_conf_scen_protocol() but later configuration calls should not mutate these port selections again. Having the convenience of doing this with a collection of plugins in a with block is syntactically nice imo.

from pluggy.

Thanks for the use case @goodboy !

I think it is perfectly fine to add this. 😁

I wonder though, we might implement this functionality using just PluginManager.register:

with pm.register(plugin):
    # plugin will be unregistered after the end of the block

I think it is pretty readable, backward compatible and we don't need to add a new API. It doesn't let you register multiple plugins in a single call, unless we change the PluginManager.register signature to support multiple plugins, which is also possible & backward compatible.

from pluggy.

@nicoddemus to make this backwards compat won't we need to still return the plugin name?

If so then I'm not sure how we can use PluginManager.register unless we return a new type (of course supporting __enter__ and __exit__) where the returned value is str-like?

I guess it's possible but seems a bit confusing and messy to implement.

from pluggy.

We can declare a single Plugin that depends in more plugins, but AS things are, pluggy is unaware of dependent plugins

from pluggy.

to make this backwards compat won't we need to still return the plugin name?

Oh I didn't realize we returned the plugin name, I assumed we returned None.

Scratch that idea then, it would be too complicated to support it.

from pluggy.

@nicoddemus @hpk42 i do wonder if it would make sense to change the registration api and do major releases of pluggy/pytest

from pluggy.

You mean to no longer return the plugin name from register?

from pluggy.

@nicoddemus that would be one example, before i propose an actual api change i want to survey use-cases better

also we do have many internals that are scarry and di things the messy way (blocking plugins, registering plugins and naming plugins are all interspersed in a "fun" dictionary that simply makes a mess

from pluggy.