Project

Profile

Help

Story #4082

closed

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

Added by bmbouter over 5 years ago. Updated over 4 years ago.

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

100%

Estimated time:
(Total: 0:00 h)
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Plugin Template
Sprint:
Quarter:

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.


Sub-issues 1 (0 open1 closed)

Task #4926: switch template entirely to jinjaCLOSED - CURRENTRELEASEamacdona@redhat.com

Actions

Related issues

Related to Pulp - Task #4927: Generate template config fileCLOSED - COMPLETE

Actions
Related to Pulp - Task #4928: Implement template `update`CLOSED - COMPLETE

Actions
Actions #1

Updated by amacdona@redhat.com over 5 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.

Actions #2

Updated by bmbouter almost 5 years ago

  • Tags deleted (Pulp 3)
Actions #3

Updated by amacdona@redhat.com almost 5 years 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."-

Actions #4

Updated by amacdona@redhat.com almost 5 years ago

  • Description updated (diff)
Actions #5

Updated by amacdona@redhat.com almost 5 years ago

  • Description updated (diff)
Actions #6

Updated by dkliban@redhat.com over 4 years ago

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

Added by dkliban@redhat.com over 4 years ago

Revision 279d2b49 | View on GitHub

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

Actions #7

Updated by dkliban@redhat.com over 4 years ago

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

Updated by dkliban@redhat.com over 4 years ago

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

Updated by dkliban@redhat.com over 4 years 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.

Actions #10

Updated by dkliban@redhat.com over 4 years ago

  • Status changed from NEW to MODIFIED
Actions #11

Updated by bmbouter over 4 years ago

  • Sprint/Milestone set to 3.0.0
Actions #12

Updated by bmbouter over 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF