Future development of #scflow

[pinin4fjords]

Having looked over #scflow and thought from a couple of angles, I'm seeing a few things that might be problematic for additional development, and which might suggest alternate approaches. I'm going to highlight them here for discussion.

• Unmaintained codebase - it's coming up 2 years since the scflow R package had any commits, and I had no response when I tried to raise a PR. The workflow is fundamentally a wrapper around this package so that fact that it's been abandoned before the first workflow release is problematic, and would block any fixes we needed to push upstream, unless we forked and maintained it ourselves (dibs not me).
• Software - the scflow package is fundamentally a wrapper around commodity packages for single-cell analysis (Seurat, Monocle, MAST...). This means any Bioconda package would need to package all of those dependencies too, which would lead to dependency headaches I at least am not prepared to deal with (I've spent hours just on Seurat dependencies in the past), and a huge Docker image.
• Unfinished nf-core workflow alongside shifting standards - scflow was never completed up to a proper release standard, and those standards have themselves shifted in the years since the last commits. So even getting it working as-is is a non-trivial amount of work which I would need a very good reason to embark upon.

I think there's an alternate approach we should consider before attempting all the work that addressing those concerns would entail:

• Write modules for the commodity R packages. This will require CLIs, but such already exist for e.g. Seurat, Scanpy, dropletUtils, Monocle (disclaimer: I was involved in all of those). These may need updating, but at least they're there, with the Biocontainers etc.
• Write workflow logic with explicit calls to more clearly named modules (e.g. seurat/find_clusters). This could be a new workflow, or we could talk to the #scrnaseq folk about extending there.

Possibly under a different name, this would make the workflow more understandable to those used to working in the single-cell field (who might then want to contribute). It would also make simplify the software stack and make individual components more useful to other workflow builders.

Bottom line: without the cooperation of the original author, getting scflow up-and-running with the existing structure and strategy will be a lot of labour, which I think could be better deployed.

[Zethson]

An alternative could be to ask the developers of https://github.com/DendrouLab/panpipes @bio-la whether they're interested in bringing panpipes up to nf-core's standards (implemented in nextflow then of course) which could then replace scflow. We should of course also ask their developers for their longterm plans.