automatically create pipeline when creating a plugin

[chhsiao1981]

It has been consensus that we are reducing the complexity of ChRIS by changing "pipeline" to be "(software) packages", and extremely deemphasizing plugins.

For the plugins, we have concluded that we should automatically create the corresponding 1-plugin pipeline when creating a plugin.

This should be done in the CUBE to provide coherent pipeline-related data/info across different versions of UI.

[chhsiao1981]

@rudolphpienaar ～

I believe we need your input as what's the unique features of "plugins" that
you definitely need the "plugins" in addition to "pipeline"～

cc: @jennydaman

[rudolphpienaar]

For this conversation, I will use "reference" to refer to chris.tch.harvard.edu and "nx" to refer to chris.tch.harvard.edu:5222

In the community of users who currently use ChRIS, the word "plugin" is well understood as well as what it means. Consquently de-emphasizing plugins "extremely" is not indicated. Thus I don't think there is "consensus". I'd say right now there is a conceptual idea/prototype in "nx" that shows promise but is far from complete.

I agree that simplification (or I would rather say streamlining) is an important goal. However, I believe it remains important to have "plugins" remain first class objects in the ChRIS UI. There is considerable work that has gone into the UI for plugins -- none of this has any analog in "nx".

• The reporting of "plugins" in the "reference" UI provides important information, including a rendering of the relevant README, use cases, etc.

• The concept of "plugins" in the reference is fundamental to the concept of how the store operates. Currently the "store" is a "store" of plugins, not pipelines. A key usability feature of the reference ChRIS is to hit the "Store" tab and be able to install new plugins (or versions) from the global store.

• The "pipeline" UI part of "reference" was always cludgy and not a very good experience. The "nx" branch simply uses the "reference" pipeline UI.

While I do like the idea of 1-plugin pipelines as a concept, however much about the implementation remains. Throwing away all the work around plugins currently represents a large regression and loss of features.

[chhsiao1981]

@rudolphpienaar

Suggestion for the 1-plugin pipeline:

1. detect that it is a 1-plugin pipeline and use plugin-UI to display the pipeline.
2. have the tags for the pipeline to easily group the 1-plugin pipeline.

[chhsiao1981]

@rudolphpienaar

I believe it will be much simpler if we simply talk about "(software) packages", not "plugins" / "pipelines".

As for the stores (I prefer to change it to other names not financially related, ex: "hub"), stores still can present the "(software) package" list, and have the users directly install the "(software) packages" from the stores.

Similar to how installing a typical "(software) packages" works, the plugins are the dependencies of the packages and are installed automatically when installing a (software) package.

[jennydaman]

@chhsiao1981 I agree with you that there are better names than ChRIS "plugins" however there is a difference in how to decide what to name versus whether to rename something.

• The word "plugin" is already familiar to FNNDSC faculty such as Ellen, Banu, Ai, ... So changing the name from "plugin" would be disruptive.
• Although the word "package" makes more sense from a software engineer's perspective, keep in mind that ChRIS's target audience is not to software engineers, but rather researchers/physicians.

[jbernal0019]

Plugins and pipelines operate very differently in many respects. A plugin is registered with a ChRIS system by a ChRIS admin. It has many software-related concerns such as versioning, software dependencies, etc... On the hand a pipeline is more of a researcher workflow that can be created by any user. Doesn't have to be a ChRIS admin. Creating a single-plugin pipeline when a plugin is registered by a ChRIS admin seems OK. That particular pipeline would be owned by the ChRIS admin. But it doesn't stop other users from creating the same pipeline with a different name and/or default parameters.