Future of Python version support re: hvac

[briantist]

The hvac library which this collection depends on has some new maintainers (yay!) and they are looking to start aggressively dropping support for EoL Python versions, see:

• Drop Python 2 and EOL Python 3 versions hvac/hvac#819
• Readding 3.6 support hvac/hvac#823

This is a good thing, and not unexpected. As it relates to Ansible and this collection though, it leaves some things up for discussion. While the Ansible controller Python support will similarly be aggressively dropping supported Python versions, as usual the versions supported for modules will still include pretty old versions.

We've already dropped support for 2.7 and 3.5 with the expectation that hvac would drop them with its 1.0.0 release.
3.6 will be dropped from hvac at the end of the year and then they will follow Python's deprecation.

So I've been thinking about whether to follow suit or not. If we do, it's a lot easier to ensure support for the latest hvac version, and that we can rely on any of the latest features and bugfixes. But that will severely limit the support for older but still used Python versions in modules.

Instead I'm leaning toward keeping support that's closer to Ansible's supported module Python versions. This should be ok because older versions of hvac that support those versions will still be available to install.

The difficulty in that comes from:

• testing: we don't currently test against multiple hvac versions
  • ansible-test doesn't really have support for running multiple test runs against different library versions
  • maybe we could fudge it by changing the requirements files and do separate runs
  • maybe we could use tox
  • either way it's a kind of significant change
  • there's already significant pressure on the CI re: concurrency limits, adding more jobs will further slow them down
  • we will get implicit testing of different hvac versions by way of when we run the tests with older python versions, older hvac will get installed, however we won't get full coverage (newer python versions will only get newer hvac versions); this might be enough...
• in authoring plugins and modules and utils:
  • we need to be more aware of the versions of hvac and what they support (we already need to do that, but... more)
  • (complicated by testing difficulties)
  • means writing more code and working around bugs that are fixed in newer versions but not older ones
  • unable to use new features, so have to keep around code we'd rather defer to the library
• more difficult to drop versions in advance
  • if we find ourselves with a need to drop an EoL module-side version of Python before Ansible does, we are probably going to hit it without much notice, making a 6-month/major version deprecation period difficult or impossible

Despite these drawbacks, I think it might be the best balance. It does not mean we'll keep supporting EoL python versions on the module side for as long as Ansible does; we may reach a point where that just becomes too burdensome without hvac support and fixes, and have to drop them.

As described above, that's not always going to be possible with a long deprecation period, and we're more likely to run into sudden issues by way of declaring "support" for things that are not actually supported by our dependencies.

---

This isn't written as a question because it's mostly just me getting thoughts out and trying to get feedback from the community. Please let me know what you think!