# CfgMgmtCamp 2026 discussion (12/12): Deprecation of behavior before providing alternatives

**URL:** <https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-12-12-deprecation-of-behavior-before-providing-alternatives/45299>\
**Category:** Collection Development\
**Tags:** cfgmgmgtcamp, deprecation, ansible-core\
**Created:** [February 7, 2026, 9:03pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-12-12-deprecation-of-behavior-before-providing-alternatives/45299 "2026-02-07T21:03:50Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [February 7, 2026, 9:03pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-12-12-deprecation-of-behavior-before-providing-alternatives/45299/1 "2026-02-07T21:03:50Z")

</div>

# 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](https://github.com/ansible/ansible/blob/6b5301eba7ce385056af747f309c11b5cbf79095/lib/ansible/plugins/strategy/ __init__.py#L702-L707); 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](https://github.com/ansible-collections/community.sops/blob/1b44ea61d0a2bde516f5010b0b9e203229a9beb2/plugins/action/load_vars.py#L108)).

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](https://github.com/ansible/ansible/issues/84830) 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](https://github.com/ansible/ansible/issues/84830#issuecomment-2867936695)).

There was a [PR to introduce an API](https://github.com/ansible/ansible/pull/85797) for ansible-core 2.20, but unfortunately [it was scrapped last minute](https://github.com/ansible/ansible/pull/85797#issuecomment-3320183635). Unfortunately something else **did** end up in 2.20: a [deprecation](https://github.com/ansible/ansible/pull/85323) 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](https://github.com/ansible/ansible/pull/86241) 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.)