Rationale
Currently, charmcraft init produces a kubernetes-based charm with the minimum layout for a functioning charm and just a few extra files that correspond to a well structured project (like CONTRIBUTING.md or tests/test_charm.py files).
Being that structure very useful in several cases, it’s common though that many developers have more advanced or specific needs for their charms, and it’s a good idea to be able to provide base charms through the init command to fulfill those needs.
The current specification introduces the concept of “profiles” to the command, which will allow us to provide different base charms and simplify the inclusion of other charm types in the future.
Related to this change, as we will be producing both kubernetes and machine charms, we need to reflect this in the general Charmcraft documentation.
The ‘profile’ mechanism
The charmcraft init command will set up a basic charm structure according to a new --profile command line option.
For backwards compatibility, if no --profile option is given when executing the command, the current structure (as it’s defined in Charmcraft 2.0) will be produced; this profile will be called simple.
Two other profiles will be introduced in this initial phase: “kubernetes” and “machine”. These two profiles will use templates to provide full fledged charms that not only contain the structures for the simple profile, but also other ones more suitable for complex projects (e.g: Github CI configuration).
After this mechanism is enabled, it will also simplify the addition of new profiles in the future, as any specific need could be covered by adding a new profile to the tool. It’s specifically left out of this design, but not discarded for a future improvement, the ability of charmcraft init to work based on user-provided templates (instead of the builtin profiles ones).
To be defined: @jnsgruk will provide examples for the new “kubernets” and “machine” charms, from which the templates will be distilled.
Other related improvements
The following are other improvements part of this overall work:
-
add documentation links where they correspond to the different created assets by the
initcommand (e.g. first line ofmetadata.yamlshould include the link to the metadata docs) -
review and improve Charmcraft’s project files (particularly the README) and general Charmcraft documentation to reflect that Charmcraft is not only to create kubernetes based charms, but also with machine ones