Drop Python 2 and EOL Python 3 versions

[colin-pm]

This builds on #739 and closes #582.

I think besides dropping Python 2 support, Python 3.6 and older should be dropped as well as they are EOL. This library should track with Python version support.

Same TODO as mentioned in #739

• Validate expected behavior installing the module in both Python 2.7 and 3.x using test.pypi.org before shipping this!

[codecov]

Codecov Report

Merging #819 (a9c2459) into develop (3426aed) will increase coverage by 0.33%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #819      +/-   ##
===========================================
+ Coverage    77.52%   77.85%   +0.33%     
===========================================
  Files           63       64       +1     
  Lines         3546     3608      +62     
===========================================
+ Hits          2749     2809      +60     
- Misses         797      799       +2     

Impacted Files	Coverage Δ
hvac/api/secrets_engines/__init__.py	100.00% <0.00%> (ø)
hvac/api/secrets_engines/ssh.py	96.72% <0.00%> (ø)

[colin-pm]

Wasn't able to write to the hvac module on PyPI test, but did some testing by creating a hvac-test module. Everything looks good to go, where Python 2 will fetch the last release, and Python 3.7 and up will fetch the upcoming new release.

[briantist]

@colin-pm I asked explicitly in #582 which python3 versions would be supported, since I maintain a project that depends on hvac. Python 3.6 was stated as the minimum then, and that helped me to set a deprecation period for support in my project.

It would have been better to have notice so that projects that depend on hvac can prepare by pinning CI versions, or ideally, setting a reasonable deprecation period for their projects.

With the sudden decision to drop 3.6, it puts projects like mine in a position of scrambling to address it on short notice.

I don't disagree with the decision to drop EoL versions of Python, but please consider providing more notice of breaking changes.

[colin-pm]

@briantist Apologies, I didn't mean to step on your toes with this change. This is a learning process for me and I'm trying my best to not make too many mistakes here.

I'll create an issue and pin it detailing the upcoming 1.0.0 version of hvac. I'd like to get a new release out the door by the start of Q3. Hopefully that provides enough time, otherwise I'm open to suggestions.

[hugovk]

can prepare by pinning CI versions

This shouldn't be necessary (as long as you're not using ancient pip) because the python_requires=">=3.7" metadata will ensure this new one is only installed for 3.7+, and pip will fall back to the last supported one for 3.6.

[colin-pm]

Yes, Python 3 versions older than 3.7 will not be able to use the upcoming 1.0.0 version.

The testing related to this PR conducted on the test PyPI instance confirms this.

[briantist]

To not get off on the wrong foot 😅 I'll say that it's good to see some movement in the project; Jeff has done a great job and I just now saw the issue looking for new maintainers. So welcome! I'm looking forward to contributing and helping out where I can as well.

Start of Q3 is just over a week away... I know 1.0.0 was originally slated for a long time ago so it makes sense to get it out the door.

I might recommend keeping 3.6 for now, while also deprecating it and setting a date for a 2.0.0 that drops it. As an example, in the Ansible world, we typically announce breaking changes at least 6 months in advance.

Doesn't necessarily have to be that long for this project, just trying to give an idea of the type of timescale.

can prepare by pinning CI versions

This shouldn't be necessary (as long as you're not using ancient pip) because the python_requires=">=3.7" metadata will ensure this new one is only installed for 3.7+, and pip will fall back to the last supported one for 3.6.

Right, hopefully not; but the main idea is having time to work these things out, and to plan and announce dropping of 3.6 for my project.

[colin-pm]

To add a little insight into my decision making process, I did read through #582 and saw that 3.6 was stated as the minimum supported version after dropping 2.7 support. However, the discussion thread was from a time where 3.6 was not EOL. I figured there wouldn't be a huge consequence from dropping 3.6 support.

If keeping 3.6 support is important for downstream consumers, I would be okay keeping it until the end of this year. After that I would like to keep hvac aligned with the supported versions of Python. Since those dates are always clearly defined, it should prevent issues like this from occurring again in the future.

[hugovk]

In my experience, python_requires does a good job allowing older Pythons to install a compatible package.

If a you're depending on hvac, you're also depending on requests, which has already dropped 3.6, and this pip mechanism is already in action and (hopefully!) working fine.

More generally, I recommend all projects plan and track the CPython EOL dates (3.6 EOL was 6 months ago, 3.7 will be in 12 months) because many projects follow it, and you never know when a dependency (of a dependency (of a dependency...)) will drop it. (Scientific Python projects also drop non-EOL versions, see NEP 29.)

More importantly for security reasons: 3.6 is no longer receiving security updates and we should encourage people to upgrade.

[briantist]

To add a little insight into my decision making process, I did read through #582 and saw that 3.6 was stated as the minimum supported version after dropping 2.7 support. However, the discussion thread was from a time where 3.6 was not EOL. I figured there wouldn't be a huge consequence from dropping 3.6 support.

It does make sense yeah. I don't expect technical issues, it's more about setting expectations for downstream projects.

If keeping 3.6 support is important for downstream consumers, I would be okay keeping it until the end of this year. After that I would like to keep hvac aligned with the supported versions of Python. Since those dates are always clearly defined, it should prevent issues like this from occurring again in the future.

I would appreciate that, and I'm fully onboard with the plan to drop unsupported versions as they go out of date. Having that be announced and expected, I agree it would prevent anyone from being surprised.

@hugovk I totally agree, and I don't advocate extending support for unsupported versions generally.

I don't know how familiar you are with Ansible, but there are several reasons why it can be a complex issue for it. I won't bore you with too much detail, but while the project itself has committed to drop unsupported versions (current earliest version is 3.8, and will be 3.9 in the next release), that is for the execution of Ansible itself (called the controller), while the parts that execute on remote hosts, support much older versions, because remote systems are not always able to change so quickly.

A project like mine (called a "collection") has a dependency on hvac so no matter what, even for remote hosts, I cannot support such old versions, and that's totally fine, but it is important to let users know. Since collections are not python packages and are not pip installable, it's not as simple as relying on those type of constraints.

End users must know the python packages needed to support the Ansible modules they want to use (out of the hundreds that are available covering wide ranges of configuration and automation).

Anyway I don't expect any upstream package like this to be taking such specialized uses into consideration, just looking for breaking changes to have a generous announcement period.

---

In the end, I will work around whatever I need to, as best I can; I hope it's clear I don't mean to stand in the way of progress!

[colin-pm]

Okay, I'll add 3.6 support back in. However, I will keep the change to move the integration tests to 3.7. I'll also add a small notice that all EOL Python versions will be dropped at the end of 2022.