Project

Profile

Help

Story #4082

As a plugin writer I can use plugin_template to bootstrap or update a plugin

Added by bmbouter about 1 year ago. Updated 4 months ago.

Status:
MODIFIED
Priority:
Normal
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

100%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Plugin Template
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

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.

all jinja
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.

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 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.


Subtasks

Task #4926: switch template entirely to jinjaMODIFIEDamacdona@redhat.com

Actions

Related issues

Related to Pulp - Task #4927: Generate template config file NEW Actions
Related to Pulp - Task #4928: Implement template `update` NEW Actions

Associated revisions

Revision 279d2b49 View on GitHub
Added by dkliban@redhat.com 5 months ago

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.

re: #4082
https://pulp.plan.io/issues/4082

History

#1 Updated by amacdona@redhat.com about 1 year 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.

#2 Updated by bmbouter 8 months ago

  • Tags deleted (Pulp 3)

#3 Updated by amacdona@redhat.com 6 months 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."-

#4 Updated by amacdona@redhat.com 6 months ago

  • Description updated (diff)

#5 Updated by amacdona@redhat.com 6 months ago

  • Description updated (diff)

#6 Updated by dkliban@redhat.com 5 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com

#7 Updated by dkliban@redhat.com 5 months ago

  • Related to Task #4927: Generate template config file added

#8 Updated by dkliban@redhat.com 5 months ago

  • Related to Task #4928: Implement template `update` added

#9 Updated by dkliban@redhat.com 5 months ago

  • Status changed from ASSIGNED to NEW

The original description is different from the actual implementation direction taken. The description will be updated after a bit more planning.

#10 Updated by dkliban@redhat.com 4 months ago

  • Status changed from NEW to MODIFIED

Please register to edit this issue

Also available in: Atom PDF