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:
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
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.
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.
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!
Just as an update, charmhelpers has been released to PyPi today with the following versions:
1.0.0 - py27+py35 version of the library just before the py27 compatibility was removed. There is a stable/py27 branch in the repository so that bug fixes/backports can be made as needed.
1.1.0 - py35+ version of the library with py27 compatibility removed. This is tracking the master branch.
So if you need to maintain a p27 charm, but need the more recent charmhelpers features, then please pin as <1.1.0 in your requirements or wheelhouse.txt files (for reactive charms).
Python 3.6 is now EOL as of 2021-12-23 and will (eventually) lose support in charmhelpers. At that point a 1.2.0 release will be made. Thus if you have py35 charms (e.g. Xenial support), then please pin now at <1.2.0.
