> As plugins get more common, I suspect that we will start to have to make decisions about whether we ship stuff as plugins or shared modules
yes I have been thinking about this a lot as well
obv you guys working with nf-core would know better but, it also seemed to me that there is some degree of risk with the Plugins in that it could end up requiring more involved support over time to keep them up to date
especially considering, for example, that in your Plugin meta JSON you have to have a compatible version of Nextflow listed
It seems that scripting things that run inside the Nextflow Workflow directly, might be "safer" from any potential drift of the Nextflow framework codebase itself. Even when writing the plugin, it was apparent that I was much more subject to the whims of both Groovy versions, and Nextflow library versions.
if that is not a big deal, it seems that the plugins might be a really nice method for nf-core to make its utilities and helpers more portable and easier to use and access; you would not even need to use the nf-core
tools
to install and run it, after all.
Also by using the Plugin method, you guys could ship features and improvements faster than the main Nextflow repo can implement the same features. That has some obvious downsides as well though
another downside, of course, is the learning curve here. Its taken me about a month, maybe a little more, to figure this all out. Its a heck of a lot more complicated than stuffing functions in the
lib
dir ever was