Add a deprecation/status message to the README #649
Conversation
This is to effectively disuade people to use it and get them to look elsewhere for writing new charms (i.e. point them to the Operator Framework). Also add details of which track to use for which version of charms.
There was a problem hiding this comment.
This is a welcome addition to the guidance to use other tools for new charms that was added to the documentation when we created 3.x ref 679a9f0.
The text does include a couple of things that needs fixing though, see in-line.
README.rst
Outdated
| versions, the tool has been split into two tracks: | ||
|
|
||
| 1. For charms targetting Ubuntu focal (20.04) or earlier: 2.x | ||
| 2. For charms targetting Ubuntu jammy (22.04) or later: 3.x |
There was a problem hiding this comment.
This is a gross oversimplification of the problem at hand, and I do not think this will help guide people into making good decisions.
Why not instead cover the fact that charm-tools 2.x is hard coded to build using Python 3.6, which is equivalent of using a Ubuntu 18.04 (Bionic) base, and that charm-tools 3.x uses the Python from your build environment?
The Focal setuptools problem as revealed by the upstream Jinja2 issue is of course worth noting, and patches are of course welcome to actually fix the root of the issue as outlined in #646.
These correct the bases section, add a binary wheels section and re-drafts the reasoning behind the 2.x/3.x split for snap tracks.
This is to effectively disuade people to use it and get them to look elsewhere for writing new charms (i.e. point them to the Operator Framework). Also add details of which track to use for which version of charms.