Parking lot

[ehmatthes]

Non-urgent ideas and tasks.

Tasks

• Consider a docs/ dir that sets up a material docs site.
• Consider providing a starting GitHub task list that guides you through what needs to be done to make a working plugin. Add a roadmap_to_1.0 document to developer_resources/ #33
• Consider a template changelog that's empty, and an actual changelog for this project.
• Make a list of things to consider, ie:
  • Does the user already have a project deployed on the platform?
  • Do you/ the user need to create more than one resource? If so, how do you verify redundant resources aren't being created? How do you connect these resources?
• Include one approach for how to package the plugin.
• Rather than modifying files in place, configuration script should create a new directory in repo's parent, writing all necessary files there?
• Consider making this a package. Then user could make a new venv, install this, run it, uninstall this, and focus on their plugin.
  • Before implementing this, figure out a tool that sets up a full development environment with a dev version of Django-simple-deploy, this plugin, and maybe the fly plugin?
  • Before doing this, consider whether this will leave behind dependencies such as prompt-toolkit.

[ehmatthes]

Tests

• Test new plugin directory already exists. (should fail with appropriate message)
• Test actual CLI usage. See fix(generate_plugin.py): instantiate PluginConfig object when assigning to plugin_config #21.
• There's lots of ways to make the test output useful. For example if the assertion fails, we can grab the most relevant lines from the internal output and print them immediately, or dump them to a report that's printed at the end. See Add support for extending core CLI #26.

[ehmatthes]

Workflow tasks

• Clean up internal handling of target_dir.
• Make consistent messaging when using --target-dir or default target_dir. ie, do we show projects/ or projects/<dsd-newhost>/, or both?

[ehmatthes]

Usage

• Consider a bootstrapping tool that gives you an entire development environment for working on a plugin, including the sample project with some dev tools included.
• Move instructions for generating a plugin to docs.
• Update instructions in core to show how to quickly get a new plugin up and running.
  • git clone ... depth 1, don't need full history of this project in order to make a new plugin.
  • Link to this from this readme.
  • Link to this from home page of dsd docs.
  • Include links to specific lines and sections of files in plugin_template/ files.
• Prompt for the location where the new plugin will be written to? (with default shown?)
  • If this, remove the CLI arg?
  • Simplify validation logic
  • Reconsider where validation is called from
  • If using prompt-toolkit to support tab-completion for path, can no longer just download or clone to run this. Will have to set up a venv and then run main file.

[ehmatthes]

Documentation

• Document CLI args for this project.
• Write some maintenance docs, ie how to keep this up to date with core.

[ehmatthes]

Make plugins extensible

This is the last great plugin move that makes the project just about infinitely extensible. If I like an existing plugin's deployment approach, I want to be able to run that work and then make some modifications. Or, maybe I want to adjust some settings and then run the parent plugin.

This is much more appealing than forking and adding the customizations I want. Forking would work, but we lose out on the opportunity to have a smaller set of more refined plugins, rather than a bunch of similar and minimally refined plugins.

• Consider how a plugin might allow another plugin to extend its work.
• Currently, this would expose implementation details. ie, have I committed to all the methods in PlatformDeployer being stable? That's a much different question than "is the plugin stable".
• How could we stabilize internal implementation enough to support extensibility?
• Could/should we allow maintainers to choose whether a plugin is extensible or not? Would they make that decision as part of the generation process here, or later?
• Don't get lost in this now. Build out dsd-vps to 1.0, with these questions in mind; that's a perfect example of a plugin that should be extensible. Also, build out the refinements that have come out, that support more widespread use of dsd overall.