As a plugin writer I can use plugin_template to bootstrap or update a plugin
The plugin template has been very useful for creating new plugins. The downside is 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 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 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 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 to update plugins.
Currently the template can only update travis files because bootstrap will clobber their existing work.
HIgh Level Plan¶
The changes will all be implemented in sub-tasks to this epic issue.
Replace all string formatting with jinja templates.
committed config values:
A yml file (checked into git) will be used to store human readable values, allowing repeated, idempotent usage.
`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 documented in the file comments)
`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, and should not invoke git. The plugin writer can then use `git diff` to make sure that the changes are correct for their plugin, and gives them the option to not stage certain changes.
Problem: can't generate a new plugin template config
Solution: add command line argument for generating a config
This patch changes the name of the boostrap.py script to plugin-template. The plugin writer is now requred to generate a template_config.yml before bootstrapping a new plugin.
Adds a --generate-config argument that generates a template_config.yml inside the plugin's root directory. This config is then going to be used to generate Travis configuration and scripts.
Plugin names can now be anything. The user must specify a plugin-app-label when generating a config.
This patch removes all the command line arguments that are now represented in the template config.
The settings in the template_config.yml no longer have exclude_ prefix.
The location of where the 'app' and 'tests' directories get created inside a new plugin has been updated.
The documentation was updated to reflect the new workflow.
#1 Updated by firstname.lastname@example.org almost 2 years ago
- Subject changed from Replace plugin_template with cookiecutter to Use cookie cutter in plugin_template
I have used a cookie cutter template, but I haven't ever made one. My limited understanding is that the files already in the repo should be converted to Jinja. It would be a large diff, but I think it wouldn't be very much work.
This might actually be super easy. All the jinja variables would be in places we already do string substitutions. Id bet a simple hack on bootstrap.py could put the correct templating syntax everywhere it needs to go.
However there is at least one small reason to keep it as is. The template itself is a working dummy plugin.
#3 Updated by email@example.com over 1 year ago
- Subject changed from Use cookie cutter in plugin_template to As a plugin writer I can use plugin_template to bootstrap or update a plugin
- Description updated (diff)
- Tags Plugin Template added
After investigating cookiecutter for the plugin_template, I don't think that's going to be the right way to go for us. The main reason cookiecutter is not a good fit is because it is primarily used for creation, but is awkward for updates.
I'm hijacking this story to use as the parent issue for the next generation of the template. Original description was -"A plugin writer observed that there are projects dedicated to providing a "template" similar to what we're doing with pulp_template here: https://github.com/pulp/pulp_template/
Specifically they recommended we switch to using https://github.com/audreyr/cookiecutter and let it make the project template."-
Please register to edit this issue