Do we want to provide a processor-based template (as well)?

[jhkennedy]

Right now, the cookiecutter assumes we're making a plugin that will run one process (workflow) and create one type of product.

This is how hyp3-autorift is organized and how we historically made plugins, but we've moved to a more "processor" based plugin for most of our plugins:

• hyp3-gamma produces RTC (was hyp3-rtc-gamma) and InSAR (was hyp3-insar-gamma) products
• asf-tools produces water map and flood map products
• DockerizedTopsApp creates GUNW SLC and Burst SLC products

Supporting multiple products is typically done via a python entry points and argparse trick. Similarly,

• RAiDER only provides one HyP3 entry point but does provide others as it was an existing tool we added support to

We could:

1. Always include the basic entry point + argparse setup for multiple plugins (overly complicated and likely confusing when not needed), or
2. Provide both templates via: https://cookiecutter.readthedocs.io/en/stable/advanced/directories.html
3. Ask how many products this plugin will make (now, or later) and conditionally add in the entry point + argparse setup
4. Just document the entry point + argparse setup

[forrestfwilliams]

My preference here is to add documentation to the repo on how to implement the entrypoint + argparse setup. While we have a fair number of plugins that implement this, I don't think the added complexity is worth having it as an option in the basic setup. Also, I think many other projects could benefit from this documentation outside of HyP3. I know I would enjoy having it as a reference.

Number two could also be nice, but it would introduce a ton of code duplication.

[jhkennedy]

I think I also lean just documentation (4). Notably with (2), you can soft-link shared files so that there isn't be a ton of code duplication, but I do think softlinks are the messiest way to do that and I'm not a huge fan of that approach.