Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to install a subworkflow composed nf-core and non-nfcore modules/subworkflows. #3175

Open
kenibrewer opened this issue Sep 17, 2024 · 3 comments
Assignees
Milestone

Comments

@kenibrewer
Copy link
Member

Description of feature

As a maintainer of a non-nfcore modules library, I would like to be able to install my custom subworkflows composed of nf-core modules/subworkflows and non-nfcore modules/subworkflows into a nextflow pipeline using the following command:

nf-core --git-remote https://github.com/kenibrewer/nf-modules-demo --branch main subworkflows install demo_subworkflow

This is blocked by the fact that the ComponentInstall class assumes that all the modules/subworkflows are coming from the same modules library when instead they could be coming from different org_names and branches.

This will allow me to modularize and version re-usable subworkflows for use in my organizaiton.

Still putting together the demo subworkflow that will trigger the errors I was seeing. I'll report back when I have that.

@kenibrewer
Copy link
Member Author

@ewels Here is the other issue that is a problem for creating private modules repos.

@mirpedrol
Copy link
Member

Hi @kenibrewer,
@jvfe is currently working on adding a new feature to allow subworkflows with modules from different remotes, you can see the open PR #3083

@ewels ewels added this to the 3.1 milestone Sep 26, 2024
@awgymer
Copy link
Contributor

awgymer commented Oct 8, 2024

and version re-usable subworkflows

One of the big weaknesses of subworkflows in general and these cross-repo subworkflows is that I don't think there is good versioning.
The subworkflows install and subworkflows update will always enforce you installing the most recent version of any module within that subworkflow.

This makes it functionally impossible to fix a subworkflow on specific module versions which may or may not differ from those in the wider workflow and which may or may not break the subworkflow (i.e. if the expected input channel shapes change for a module)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants