As a collection developer/maintainer
Deprecation of behavior before providing alternatives
Latest developments
None that I know of. This wasn’t discussed at CfgMgmtCamp 2026.
Original text
This is another very personal one ![]()
When starting to use SOPS to encrypt Ansible secrets, I quickly noticed that I need a SOPS analogue of ansible.builtin.include_vars. As it turns out, it is unfortunately not possible to set variables in action plugins - unless your action plugin is called ansible.builtin.include_vars. There is literally code in ansible-core that treats the return values of ansible.builtin.include_vars differently than the return values of all other action plugins (here it is; some lines below you can see code handling ansible.builtin.set_fact differently as well).
The next best way to set variables (without lazy evaluation) is to set them as (non-cacheable) “facts”. From a user’s point of view, they behave the same way. That’s why community.sops.load_vars returns the loaded values as ansible_facts (here’s the code).
During the development of ansible-core 2.19 (Data Tagging) suddenly a deprecation popped up for facts injection. This means that if you use a “variable” (which is in fact a fact) loaded by community.sops.load_vars, you suddenly saw a deprecation message saying that fact injection will get removed soon and you should access the value through ansible_facts. I protested about this and asked for an API to set variables from action plugins, so community.sops.load_vars can set actual variables and doesn’t have to rely on going through ansible_facts. (The API should be there before or at the same time when the deprecation arrives in an ansible-core release.)
My worst fear was (and still is) that users start changing their roles/playbooks to access values loaded through community.sops.load_vars through ansible_facts - which will suddenly break if an API is there that allows to directly set variables. Eventually an API was promised, and the deprecation was removed for 2.19.0 GA (the API didn’t make it for 2.19.0 GA either) (the only public statement on this I could find).
There was a PR to introduce an API for ansible-core 2.20, but unfortunately it was scrapped last minute. Unfortunately something else did end up in 2.20: a deprecation of the default value of INJECT_FACTS_AS_VARS. Its deprecation message is printed every task where you somewhere access a fact directly and not through ansible_facts. Which basically means that anyone using community.sops.load_vars extensively sees a lot of deprecation messages, and they (mostly, though of course that depends on your playbooks/roles) point to uses of variables loaded with community.sops.load_vars.
So much for my fears, and then the hope that they were unsubstantiated…
Now it looks like we might get the API for ansible-core 2.21 (together with projections), but since the PR hasn’t been merged yet, it can still happen that it again gets postponed.
For me as a community.sops maintainer and user, this situation is simply very depressing. (I don’t want to stick to old outdated versions of ansible-core that don’t show this deprecation, and I don’t want to encourage all users to do the same.)