There is a need to more flexibly define the workflow for using apps. As it stands right now, the steps to download, install, enable an app are hardcoded with no flexibility. In some scenarios you will always have the apps already on the file system, and in that case you should have a no-op downloader. On other cases you might want to plug into a hosting providers like Pantheon's infrastructure to execute the download or a commit into vcs. In other cases you might want to authenticate to a server and exchange oauth tokens. As it stands now, none of that is possible.
There are 2 options on the table right now.
1) Define the possible steps that are needed for app install. Auth, Download, Install, etc. They are clearly defined steps and they can each be a plugin. Then each server can provide a list of which class is used for those workflow steps. Some that done need downloads can no-op, others that need authentication can sub in an OAuth plugin.
2) If we want to support arbitrary workflows, we will need to support a generic "Chain of Responsibility" workflow and allow each server to specify the classes and ordering of their chain. This has the benefit of being incredibly flexible, but the downside to that flexibility is that we will need to have a very general interface and pass all data around to each step. Makes for more flexibility at the expense of more work.
Comments
Comment #1
nedjoMost of what we need here is applicable beyond apps so we should think through how this relates to Drupal core and drupal.org developments. See #1733748: [meta] Enable drupal.org based apps.
Comment #2
rogical CreditAttribution: rogical commentedThe option 2) is someshow complex and seems can't approach in a short time, so I think we'd better to implement 1) in the 1.x release, and think about 2( in 2.x?