Temporary registration via context manager

[goodboy]

This is a proposal for a very simple new feature. I actually implemented it in a side project pysipp and was thinking it was something we could add to the PluginManger.

The jist of it is adding a way to temporarily register plugins using a context manager api:

with pluginmanager.register_all([pluginmod1, pluginmod2]) as pm:
    #... do stuff that requires above plugins to be active...

# continue with stuff that doesn't require above plugins to be registered.

So it would basically just be adding PluginManager.register_all() (or whatever name you guys think is best) method that is a simple wrapper around register/unregister.

[RonnyPfannschmidt]

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

[nicoddemus]

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?

[goodboy]

@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.

[nicoddemus]

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.

[goodboy]

@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.

[RonnyPfannschmidt]

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

[nicoddemus]

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.

[RonnyPfannschmidt]

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

[nicoddemus]

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

[RonnyPfannschmidt]

@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