I'm just trying to see if I'm understanding how plugins and callbacks are currently implemented.
From what I see that plugins are enabled by installing them in a designated _plugins directory and to disable them you have to remove it from those directories.
Callbacks are registered by providing a class that includes one or more callback methods.
It also seems to me that you can't selectively execute a callback based on the playbook/play/task that is being run.
Does that cover it in broad terms?
<tim/>
The Invocation thread here and in issue #1004 cleared up one point of confusion -- how do I know who is calling me? I think it would be useful for filtering callback execution if that dict optionally included the playbook, task and action names.
I appreciate the callbacks and modularization work so far, but its still not quite enough for my tastes. I had experience with Movable Type that had a rather extensive plugin & callback system that I'm drawing from here. That plugin system was at the core of what made MT very modular and easier to maintain because it kept extension code seperate from the core. This was a highly recommended best practice in the community for painless upgrades. That system was more configure than convention though -- something that I appreciate that Ansible does not "suffer" from. Still I can't help but think a happy medium.
At a minimum I was thinking of the current plugin paths as a default that can be overridden in the configuration. The values of those config params could contain multiple directory paths akin to PYTHONPATH.
Personally I'd suggest taking it one step further where there is one plugin directory with standard directory names such as connection, callback, action. This would mean one config param rather than one for each plugin type.
Adding or removing a path would provide a rudimentary means for enabling and disabling plugins with playing with code files and potentially impacting all users.
Am I making sense? Thoughts?
<tim/>
The Invocation thread here and in issue #1004 cleared up one point of confusion -- how do I know who is calling me? I think it would be useful for filtering callback execution if that dict optionally included the playbook, task and action names.
Yep, I've been thinking about this lately (I'll tip my hand about what
I'm wanting to do in a few short hours). We'll probably pass some of
this info to the callback module when constructing it in the near
future.
It will probably be done as setting a variable like "._playbook_info"
rather than modifying the constructor to not break any existing
callback modules.
Am I making sense? Thoughts?
I'm open to making it look in an additional configurable plugins
directory for 0.8, but it still needs to look where it looks now too.
It will probably be done as setting a variable like "._playbook_info"
rather than modifying the constructor to not break any existing
callback modules.
Not sure why they can't go under the invocation dict.
I'm open to making it look in an additional configurable plugins
directory for 0.8, but it still needs to look where it looks now too.
Right. Would where it looks now by kept to the front or be last in line when addition paths are defined?
<tim/>
It will probably be done as setting a variable like "._playbook_info"
rather than modifying the constructor to not break any existing
callback modules.
Not sure why they can't go under the invocation dict.
I want to supply it all callbacks, not just one method.
I'm open to making it look in an additional configurable plugins
directory for 0.8, but it still needs to look where it looks now too.
Right. Would where it looks now by kept to the front or be last in line when addition paths are defined?
Where it looks now would remain first.