The ChRIS Store: the Idea and the Reality

[jennydaman]

Background

The ChRIS Store is a simple web application which stores (largely immutable) data about ChRIS plugins. To add plugins to ChRIS, the ChRIS backend depends on the ChRIS store service to serve one-time static information about ChRIS plugins.

Original Vision

The ChRIS Store would be a website similar to pypi.org with rich features such as user group collaboration, sharing pipelines, rating, search. It should be the primary destination and resource for all information regarding ChRIS plugins and pipelines.

Reality

• The ChRIS Store project (both ChRIS_store backend and ChRIS_store_ui) are orphaned projects, development effort is mostly non-existent.
• github.com is preferred over chrisstore.co as a website for information about a ChRIS plugin. i.e. we (users, developers) conceptualize the process of plugin registration illegitimately as going from a Github repo into CUBE, we don't think about going from a ChRIS store URL to CUBE.

Criticisms

• The ChRIS store is an inconvenient and seemingly unnecessary step for registering a plugin to ChRIS.
• Upload spec is fragmented: why are plugin_name, public_repo, dock_image not part of the JSON description of a plugin?
• There does not exist a specification for what a valid ChRIS plugin is between the Store and CUBE.
• Search is inflexible, inferior results compared to search on github.com, google.com
• lack of universal identifier for a ChRIS plugin. The unique identity of a plugin is a 2-tuple of its (plugin_name, version) which can be different between Stores and CUBEs.
• Cost of maintenance
• Code duplication between ChRIS_store and ChRIS_ultron_backEnd

Missing Features

• Pipelines cannot be registered from Store to CUBE
• ChRIS_store_ui does not display plugin parameter information
• ChRIS_store_ui does not support pipelines

Imagining ChRIS Without the ChRIS Store

• Plugin descriptions and pipelines can be hosted and versioned on github.com
• Register plugins and pipelines directly from github.com to CUBE, i.e. using chrs for YAML pipeline-files, optionally using CI to "push" to CUBE.
  • It is not currently possible to upload a plugin to CUBE without the Store.
  • alternate idea: CUBE a container registry tag for it to pull information from image annotations
• The ChRIS_ui and CUBE should allow for plugins to be browsed by anonymous users (i.e. without logging in)
• It should be possible to register plugins from CUBE to CUBE.
• Abandon the ChRIS_store project and reallocate resources/thinking.

Reflection

The idea of the ChRIS_store is reasonable, however the ChRIS project has not at the point where a dedicated "store" is necessary, in terms of supporting a large community of ChRIS pipeline authors and ChRIS plugin developers, sharing plugins between different instances of ChRIS, ...

[jennydaman]

A unified ChRIS Store and ChRIS backend would enable a feature of the ChRIS_store_ui where exemplar feeds for plugins are displayed in the plugin details pages. Seeing examples of usage, input files, and output data, are the most common thing users look for when browsing software.