Should all pathway reconstruction algorithms be dockerized?

[annaritz]

I'm planning to write a simple all-pairs-shortest-paths algorithm, which can be done with NetworkX in Python. Should this be dockerized, to maintain consistency within the framework? What about more involved algorithms that will be implemented as part of spras, like ResponseNet?

[agitter]

My initial thought is that any algorithm that can be written in Python with versions of Python packages that are compatible with our conda environment do not need to be dockerized. One benefit is that a portion of SPRAS would be accessible even without Docker. Docker images also incur some overhead in storage space and runtime.

My current heuristics are:

• No Docker: Algorithm can be written in Python with reasonable Python dependencies or is a third-party package that can be imported as a Python module with reasonable dependencies
• Borderline: Python-based algorithm can be imported but requires several unique dependencies that expand our conda environment (e.g. GraphSpace)
• Docker: Python-based algorithm requires many unique dependencies, old versions of packages, or dependencies that are not pure Python or not available on all platforms; also non-Python-based algorithms

A consideration for long term maintenance is that third-party packages may evolve and require versions of Python packages that conflict with those in our environment in the future. We could defer that discussion until we decide whether and how to support multiple versions of an algorithm.

If we are writing our own network algorithms, it would be nice if the run function was modular enough that it could be imported and used by a different Python project. I believe our current design is sufficient for that.

One reason to dockerize all algorithms would be to make them available outside of SPRAS to someone who does not want to install all of the SPRAS Python package dependencies separately. Do we anticipate much demand for that? I don't at this time.