Story #4082
Updated by amacdona@redhat.com almost 5 years ago
The A plugin template has been very useful for creating new plugins. The downside is writer observed that since it is used only to create new plugins, it is not used frequently. The recent addition of generate_travis_config demonstrates that the template can also be useful for updating plugins, which will both increase usage and save plugin writers time. As we there are expanding the usage, the following issues are arising: Problem 1: args instead of config. One pain point with generate_travis_config is that all the variables are set at runtime, so plugin writers need projects dedicated to remember the exact command used to generate their travis if they want to run it again to update those files. This concept will be providing a pain point for anything that the template is capable of updating. Problem 2: Multiple template types Some files are templated with string processing, some are templated with jinja Problem 3: Difficult "template" similar to update plugins. Currently the template can only update travis files because bootstrap will clobber their existing work. h3. HIgh Level Plan *all jinja* Replace all string formatting what we're doing with jinja templates. pulp_template here: https://github.com/pulp/pulp_template/ *committed config values*: A yml file (checked into git) will be used Specifically they recommended we switch to store human readable values, allowing repeated, idempotent usage. *New CLI:* `plugin-template init [path/to/plugin/parentdir/, defaults to ../]`: * Wizard asks user for any config values necessary to bootstrap the template. * Create a root directory for new plugin * creates a user-editable template-config.yml file in the plugin root dir that stores all the config values (all values commented in the file) `plugin-template bootstrap <path-to-plugin-rootdir>`: * Reads the template file at <path>/template-config.yml * render files conditionally based on yml. (ie, if deploy-pypi-client is set to false, don't template that file) `plugin-template update <path-to-plugin-rootdir> [--file-path <path>] * Reads the template file at <path>/template.yml * similar to bootstrap command, but act only on "managed files" which are files which should not be updated manually by the plugin author, ex .travis/script.sh * if --file-path <path> is passed, render that file only. this can be used to deliberately clobber files that need updating, but are not "managed files", giving the plugin author granular control. Note: All changes should be made against the filesystem only, using https://github.com/audreyr/cookiecutter and should not invoke git. The plugin writer can then use `git diff` to let it make sure that the changes are correct for their plugin, and gives them the option to not stage certain changes. Story 1: Begin a new CLI by refactoring `bootstrap` to use jinja templates. Bootstrap will create a new plugin from scratch and populate all the files. Story 2: Add `init` command: Creates a root directory for the new plugin and places a yaml file in it. The yaml file is populated with all variables necessary to run `bootstrap`. Story 3: Add `update` command: Update "managed" files only. Files that should not be updated by plugin writers are called "managed files". The base list of these files will be determined by the options in the yaml file. ie, `publish_client_gem.sh` might be left out based ont th project template.
.