I saw this and was wondering how the tooling here is working with nf-core? Does this integrate into wave or are they building something else? blog.bioconductor.org/posts/2026-10-07-biofair-cofest

I've got to run to pick up my kid at nursery, but the idea is that: • Bioconductor packages developer add YAML and R files in their packages, under

inst/biocjobs/

, e.g. github.com/kevinrue/DropletUtils/…/biocjobs • the BiocJobs package itself uses those files to produce wrappers (for Nextflow as well as other workflow managers) e.g. github.com/kevinrue/DropletUtils/…/wrappers • in the case of Nextflow, those wrappers can be reused as-is in workflows, e.g. github.com/kevinrue/biofair-nextflow-pipeline (hopefully in the future pulled somehow rather than copy pasted as right now) You'll notice that I've literally been working on this (and fixing glitches) today, so it's very much at the proof of concept stage. Feedback more than welcome!

As we chatted about in Cambridge Kevin, I'm very excited by the possibilities! We spent loads of time at the EBI writing CLIs for packages for exactly this reason- including for dropletutils (github.com/ebi-gene-expression-group/r-seurat-scripts, github.com/ebi-gene-expression-group/dropletutils-scripts), but it's a real barrier for BioC workflow usage

Thanks @Jonathan Manning I'm already running into some interesting challenges, writing the R scripts being wrapped in a way that 1) is compatible with all target environments (Nextflow and Galaxy to start with in my pilot) 2) lets the Nextflow pipeline organise outputs cleanly See for instance github.com/kevinrue/biofair-nextflow-pipeline/issues/2 At this point - early days - I'm allowing myself to be a little messy, for the sake of building a multi-step pipeline demonstrating the concepts, but I'm very keen to collect feedback on tweaks and fixes to meet Nextflow and nf-core best practices, in due course.

Will you be at the hackathon?

Unfortunately, not in person, but I'll have some time to contribute/communicate online

Keep us updated about the hybrid hackathon you're planning. I don't have the time at the moment to look over what you've got, but as long as I remember, I'll take a look later on.

Will do! There are quite a few moving parts involved and more documentation is needed, which is why I'm rushing a bit the minimal wrappers and workflow, to build a collection of examples that I can use to illustrate the process when onboarding new contributors. With what I've built so far, I'm hoping to have a basic contributor guide in the next couple of weeks. I also spotted some updates needed in BiocJobs itself (the package doing the wrapping) to 'fix' some aspects of the Nextflow wrappers being produced. I'm coordinating with the maintainer of the package to get a PR in asap. I'm helping teach in Oxford this week and next, which is why I couldn't fit a trip to Barcelona, unfortunately.

FWIW I don't think you should focus on Nextflow/ Galaxy wrappers. They'll be superseded immediately when someone decides nf-core standards need to evolve and you have a maintenance headache. All we we really need for cross-community magic is CLI access to the 'sanctioned paths' of the BioC packages in question.

Would

pixi-build-r

be sufficient to make packages for conda and go from there? github.com/prefix-dev/pixi/issues/1543#…

Maybe what is more interesting to you then is BiocExecute osf.io/preprints/biohackrxiv/ywsmq_v1

Would

pixi-build-r

be sufficient to make packages for conda and go from there? github.com/prefix-dev/pixi/issues/1543#…

I'd really like for there not to be another layer of packages to be maintained, so for BioC packages to come with CLI scripts in-built (or some functionality that looks like that)

I need to understand better what's going on. Is there a writeup of what's currently not compatible and what's being explored - i.e. some kind of project onboarding?

In terms of compatibility, it's hard to pinpoint a specific example as I find it hard to track down modules wrapping individual Bioconductor 'tools' (i.e., scripts, not packages or functions), let alone checking whether their inputs and outputs (file types) are compatible with each other. This is basically the challenge we're exploring: moving those task-oriented wrapper scripts to the R package itself as a 'source of truth' that is directly sitting next to the package's own source code. For instance, @Jonathan Manning rightly pointed at github.com/ebi-gene-expression-group/dropletutils-scripts as an example for DropletUtils which produces the conda package that is eventually picked up by pipelines like scdownstream I'm not sure how many users of the module would immediately know where to look for the R code being executed by the module: I notice that anaconda.org/channels/…/overview links to the bioconductor website rather than the EBI repo producing the conda package. == In terms of project onboarding, short answer is that this is basically being written and updated as we are building up the infrastructure in our pilot. It also depends which part of the project one is interested to contribute to. From the perspective of someone developing the wrappers themselves, the BiocJobs developer guide is currently my own reference. From the perspective of testing/applying the generated wrappers in a Nextflow pipeline, I have been taking notes from my own experience over the last week or so, and I still need to tidy up those notes into a guide that is readable by others

How would github.com/r-lib/ir fit into this?

I'm not familiar with

ir

. I need to catch up and get back to you on that one. In the meantime, I've started this contribution guide on the repo of the (demo, can't emphasise that enough) Nextflow pipeline, does this help as onboarding materials? did i miss your point entirely? would you be willing to open github issues to flag missing information you'd like to see?

I can do that. I'll take a look later

Thanks. I chose that pipeline as a place to draft some initial targeted information, but if you were thinking of more general pipeline-independent onboarding materials, we'll have to think about another more suitable location. I think it's useful to have a concrete test case to look at, to discuss issues and challenges on a concrete example

I'm still trying to wrap my head around this. So this is basically what would be

template script.R

but in a shareable form that works in whatever workflow manager?

Basically. The idea idea is reduce redundant 'wrapping' work downstream of the package. I must say that it has surfaced some challenges in writing a single R script that "works everywhere". For instance, you'll find a somewhat questionable hack removing the output file if it already exists: this is because Galaxy creates an empty placeholder output file, which in the case of

anndataR::write_h5ad()

causes an error as the function refuses to overwrite files and doesn't have an option to force it.

and I presume Galaxy has a good reason to have a placeholder output file?

Let me get back to you on that one. I only remember a hand-wavy answer (or maybe i wasn't listening carefully)