https://nf-co.re logo
Join Slack
Powered by
Is anyone working on a template for plugins? Eithe...
# nextflow-plugins
m
Is anyone working on a template for plugins? Either GitHub template repo, cookiecutter, or similar? If not, I might make a cookiecutter.
❤️ 1
m
I was thinking about doing something like that. We can try to do something together, if you want.
🙂
m
Sure, I'd be happy to. What templating tooling were you thinking of using?
m
What I had in mind was to work on nf-core tools to do that and then, from within it, using jinja like they’re using.
m
Right, that's basically like using cookiecutter (which also uses jinja2 for templating). Does it really make sense inside nf-core tools, though? I'm asking since plugins are more general and not nf-core specific or are they?
j
But are you talking about plugins for nextflow or nf-core? I'm starting a new plugin for nextflow (nf-events for kafka, sqs, rabbitmq) and I started cloning nf-sql becsuse nf-hello is very basic (but complete)
m
I'm talking about a general plugin template for nextflow. I don't know what @Marcel Ribeiro-Dantas has planned.
m
My original idea was to discuss this within the nf-core community, if they had plans to have a guideline for plugin building or something like that, and then build it within nf-core, both for nf-core plugins and nextflow in general.
j
Haha nor @Marcel Ribeiro-Dantas knows
m
🤣
The plugin is definitely for nextflow.
What I was wondering is if we could have it as parte of the nf-core tools + guidelines on how to do it like nf-core does for other things.
j
Imho is a todo un nextflow not un nf-core
m
You don’t have to make your pipeline an nf-core pipeline to use the nf-core tools.
m
The question is if there is an intention to have nf-core specific plugins I guess?
m
j
Julia has created a nextflow plugin using ideas/Code from corr
m
Yes, it’s the one above.
j
Exactly, nf-validation
m
But maybe it’s a better idea to have it independent of nf-core. It’s something I was still reflecting upon
m
Right, but are there any nf-core specific conventions about the plugin? Or is it just a normal nextflow plugin for the validation purpose?
j
(I'm with the mobile an cant write as you speed Marcel)
🤣 1
m
Not that I am aware of. This is the type of discussion I was planning to start
🙂
m
I would lean towards having a general template outside of nf-core tools.
👍🏻 1
m
For the second question, it’s a nextflow plugin for nf-core usage. https://nf-co.re/pipeline_schema_builder
👍 1
But you want to send this as a PR to nextflow, or have a third new software for that?
m
I gotta run now but happy to talk more tomorrow.
m
I’m not really in favor of building a 3rd tool for this. I would rather have it within nextflow or within nf-core tools.
Sure! 😉
m
A template repository on GitHub could be a solution.
👍🏻 1
m
True, though a bit static. I haven’t thought much about it, but I suppose we could have different plugin templates depending on what the plugin plans to do
Something in the CLI could allow us to do this easily, though we could also have git branches for the options, of cours.e
m
Take a look at cookiecutter, too.
m
But then it’s a new software that must be installed, right? 😅 I would like to avoid installing another tool just to get a template for a nextflow plugin
p
For this I think a GitHub template repo (or several) is ideal.. Nextflow, not nf-core
I'm not sure how plugins would be nf-core specific in any way? And would there be that much that we could handle with variables etc?
Cookiecutter / jinja is nice but adds a fair bit of complexity. Unless we have a clear idea of what variables would be templated, im not sure it would be worth it (also not that many people using it)
m
I took a bit closer look at template repos but as far as I can see the only advantage is that it's not a fork? 🤔 That would be a bit underwhelming to not have any variables.
p
Let's start by ignoring tool chain and thinking about what variables we do want to start with..
m
Things that come to mind immediately: • plugin name • author • desired license
Could go further by suggesting a config scope based on the plugin name.
So variable replacement is definitely not a feature with GH template repos https://github.com/community/community/discussions/5336 There are some hacks mentioned there and also, e.g., https://rclayton.silvrback.com/templatizing-github-template-repos but at that point I don't see why not to use something like cookiecutter.
Here someone combines a GH action run with cookiecutter to generate the repo https://simonwillison.net/2021/Aug/28/dynamic-github-repository-templates/ I guess, it's nice to shield users of the template repo from cookiecutter but it also means that input variables are limited to what can be fetched from the GH API.
p
Huh, that's a nice pattern. Could do the same but instead of on 
push
could do 
workflow_dispatch
- then you could have a form with whatever variables you want
m
If I understood correctly the intention is to run this on first push (when the new repo is initialized from the template repo), and basically replace itself.
How do you see the interaction with 
workflow_dispatch
, when and where would a user fill out this form?
p
Fork, then go to Actions, select the named action, then use the dropdown. eg. as we do on nf-core/tools here
Open in Slack
PreviousNext
Powered by