A proposal for an alternative way of managing Applications

[funnell]

Code for multiple Applications is typically contained within a single repository that would be installed into a user's environment. A couple consequences of this is that

• As App versions get updated, it becomes more difficult to run older App versions
• App developers will be (understandably) tempted to share some common code across multiple Apps, which itself could then change over time and potentially change an App's behaviour without the App version string or App code changing.

One solution to this is to just check out older commits of the Apps repository to run older App versions, as this would make sure that any common code used is the same as it was when the older App version was minted. However, now you would also need to manually track the repo tags or commits.

This prompted me to think about an alternative approach partly inspired by Pachyderm and the CMO's Voyager system that I hope could be considered for some future version of Isabl.

The approach could look like this:

• Each Isabl Application resides in it’s own git repository. This repo would then explicitly declare common custom code dependencies and versions, perhaps via submodules or Python package dependencies.
• Registering an Application with the Isabl database would require providing the git repo URL.
• When running an Application, the CLI could query the git repo for available tags, and present those as runnable versions in the help output.
• When a user runs an Application and specifies the version, the CLI could download that version to a configurable cache location and execute it. Also allowing the specification of a git commit hash (rather than tag name) would be useful for testing an App, but wouldn’t need to be included in the help output)

I think this approach would improve reproducibility, because each analysis would be tied to the specific state of the Application code that was used to run it (via the git repo tag or commit hash), whereas currently it is up to individual App developers to remember/decide to update their App version strings. With this scheme, if an analysis’ result files become lost or corrupted, it would be easier to ensure that the exact same result files could be regenerated, whereas now e.g. MyApp v0.1.0 could potentially refer to several different states of the MyApp code.

[juanesarango]

I'm not familiar with CMO's Voyager, but I think I understand it. And I like it. Something similar as how docker manages versions from the registries, or more specifically how nextflow manages workflow versions from github.

That's a good idea for future improvements. Let me know if you would be interested in working jointly on this.

[funnell]

Yeah I'd be interested in that. Since it would be a fairly major change it might benefit from some discussion :)