Removing py27/p35 from charm-helpers library

Hi

The charm-helpers library has, for a long time, had Python 2.7 support. However, Python 2.7 became end-of-life on 1st Jan 2020, and maintaining support for it is becoming harder.

In order to allow the charm-helpers library to be able to make use of newer features of Python, I’ve put up a pull request to remove Python 2.7 and Python 3.5 compatibility from the library.

There is already a pull request - #648 that was written that didn’t expect to have to support py27 (or py35) so I felt it was probably time to allow the library to move forward as Python continues to evolve. Python 3.5 was EOL on the 30th September 2020 and support for it in other modules in PyPi has been being removed for some time now.

I’d like to do a major version bump to 1.0.0 to indicate the lack of backwards compatibility with the pre-1.0.0 versions. If further 0.20.x versions are needed we can always spin them off the commit prior to the the break.

So if your charms are still Py27 based or need Py35 support (e.g. on Xenial) then please make sure you pin your builds to <1.0.0.

Thanks!

Edit 1

There’s an inconsistency between the PR and this post, in that the PR currently says py27/pre-py35 removal, and this post takes about py35 removal as well. I was obviously in two minds as to which way to go, and ending up in slightly different places in the PR and this post! I’m leaning much further towards removing py35 support from the library as the above indicates, and intend to update the PR to reflect this. Sorry for the confusion.

Edit 2 – 2021-12-14

So now the PR #651 has been merged, so the development branch of the library is now py3.5+ only. Still wondering if we should go 1.0.0 for the py27+py34 compatibility (as suggested by @pengale), followed quickly by 1.1.0 (or 2.0.0) for the py35+ version, or just straight to 1.0.0. There’s going to be a series of ‘drops’ in the future as py36 goes EOL at the end of this year 2021-12-23. So my current thoughts are:

  • 1.0.x == py27 + py34
  • 1.1.x == py35+
  • 1.2.x == py36+
  • 1.3.x == py37++

Thoughts?

2 Likes

This may be relevant, but in the Operator Framework, we recently had a patch to remove py35 support and ultimately decided to not merge that change. For the curious, here is that thread (and the specific comment): https://github.com/canonical/operator/pull/607#issuecomment-927845148

2 Likes

Since we are committed to providing ESM support for Xenial for some time, it might make more sense to release a charmhelpers 1.0.0 with Python 2.7 and 3.5 support, then drop a 2.0.0 release soon after, with the support removed.

Folks would still have an easy thing to pin: charmhelpers < 2.0.0. But we’d also be signaling that there is a production grade 1.x.x version of charmhelpers available, with bugfix support.

1 Like

Folks would still have an easy thing to pin: charmhelpers < 2.0.0. But we’d also be signaling that there is a production grade 1.x.x version of charmhelpers available, with bugfix support.

So, the PR has landed now. I edited my topic above to include some of what you mentioned; specifically, yes, let’s do a 1.0.0 for py27/p34 support, and a 1.1.0 for py35+ support, rather than 2.0.0. How does that sit with you.

1 Like

Yes, I’ve kept py35 support in the master branch for the moment, but will do a 1.1.0 to drop py35 at the appropriate point; or at least that’s the current working theory!

I’m good with this. Thank you :slight_smile:

1 Like