now show plugin config runtime deprecations

[bcoca]

requires #77056 to avoid spamming duplicate messages

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

config

[briantist]

It will be some time before I can test this (probably not until after it's merged, but I'll see), speaking of which should there be tests for this?

Also any chance for backports? 🙏

I have a workaround in my code for displaying deprecations, I presume that if this feature is available, then it will run before my code, and so when I check for deprecations there won't be any to display. But is there something I could check for in my code? Conditionally import or whatever to skip my deprecation code altogether?

If it helps, my code: https://github.com/ansible-collections/community.hashi_vault/blob/4a64d4cde1e8de16b91eee558d8d2d9ff3e3674f/plugins/plugin_utils/_hashi_vault_plugin.py#L50-L86

[bcoca]

@briantist backports would also depend on #77056 ,I put this together in 5 mins once i saw that as it solved the major blocker for this, so my pr 'works' but not ready to merge. I would like to tweak presentation/msg a lot more.

The issues with your code are the same as mine w/o the sivel's PR, you'll get the same message over and over every time the option is accessed (and normal flow for most plugins, man at least x2).

[briantist]

@briantist backports would also depend on #77056 ,I put this together in 5 mins once i saw that as it solved the major blocker for this, so my pr 'works' but not ready to merge. I would like to tweak presentation/msg a lot more.

Makes sense, thanks for the explanations!

The issues with your code are the same as mine w/o the sivel's PR, you'll get the same message over and over every time the option is accessed (and normal flow for most plugins, man at least x2).

Mine doesn't get called on every option access automatically; this gets called once toward the beginning of the plugin, after set_options() is called, which seems to be sufficient to trigger the existing deprecation processing (which adds deprecations to the list but doesn't display them), on options that are set, which is sufficient for my purposes but I know there are scenarios you've laid out before where that's not always the right thing. Anyway, I only ever call the function I linked once, so there's no duplicate messages that I've ever seen; possible there are and I haven't noticed.

In any case, I look forward to an "official" fix and to get rid of this code.. that'll take a lot more time if it isn't backported, but that's ok I just have to make sure my little workaround doesn't get in the way in the versions where it's not needed.

[bcoca]

@briantist yes, that makes 'less' noise and lookups only get called explicitly once, but this 'once' is per task/host in different forks, which means you still get the message N times, other plugins get set_options called multiple times, why we could not use your implementation as is (nor mine) for all plugins.

Why sivel's PR is crucial to avoid repetition as warnings get relayed to the main process and deduped there.

[ansibot]

The test ansible-test sanity --test pylint [explain] failed with 2 errors:

lib/ansible/plugins/__init__.py:59:18: too-many-format-args: Too many arguments for format string
lib/ansible/plugins/__init__.py:60:12: collection-invalid-deprecated-version: Invalid deprecated version (<Subscript l.60 at 0x7f7ddd620d90>) found in call to Display.deprecated or AnsibleModule.deprecate

click here for bot help

[bcoca]

already works in 2.19

[bcoca]

>ansible -m debug -a msg="{{q('depme', start=0, end=8, format='testuser%02x')}}" localhost --playbook-dir ./
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: Deprecation warnings can be disabled by setting `deprecation_warnings=False` in ansible.cfg.
[DEPRECATION WARNING]: format option. Reason: cause i wanna
Alternatives: nope. This feature will be removed from lookup plugin 'depme' in the future.