nf-core / tools

Python package with helper tools for the nf-core community.
https://nf-co.re
MIT License
241 stars 190 forks source link

Add ability to install a nf-core module into a private module library #3174

Open kenibrewer opened 1 month ago

kenibrewer commented 1 month ago

Description of feature

As a maintainer of a non-nfcore modules library using nf-core tooling, I would like to be able to install nf-core modules and subworkflows into my non-nfcore modules library for use building subworkflows.

This is currently prevented by this check . It could be adjusted to check if the org_name is nf_core before failing.

kenibrewer commented 1 month ago

@ewels This is one of the issues.

ewels commented 1 month ago

Will https://github.com/nf-core/tools/pull/3083 also fix this?

mirpedrol commented 1 month ago

Will https://github.com/nf-core/tools/pull/3083 also fix this?

I don't think so, we would have to adapt the command a bit to allow installing modules on a modules repo. But once combinations of different module sources are allowed, will you need to install an nf-core module into a non-nf-core repo?

kenibrewer commented 1 month ago

If you want to write an nftest case for a hybrid subworkflow then yes.

Otherwise the subworkflow can't execute in the library repo.

On Thu, Sep 19, 2024 at 05:39 Júlia Mir Pedrol @.***> wrote:

Will #3083 https://github.com/nf-core/tools/pull/3083 also fix this?

I don't think so, we would have to adapt the command a bit to allow installing modules on a modules repo. But once combinations of different module sources are allowed, will you need to install an nf-core module into a non-nf-core repo?

— Reply to this email directly, view it on GitHub https://github.com/nf-core/tools/issues/3174#issuecomment-2360505668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFHAFLREFQ6QSH4VLDZE23ZXKLTJAVCNFSM6AAAAABOMKALJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRQGUYDKNRWHA . You are receiving this because you authored the thread.Message ID: @.***>

mirpedrol commented 1 month ago

oh, that's something to take into account! 👀 🚨 So the only way in which we could test a subworkflow is to have a duplicate of the nf-core module? I am wondering if we could find an alternative, but I can't think of one right now. The reason is that nf-core modules will easily get out of sync every time there is an update on the nf-core repo and you don't update them on your repo. And even if we are installing the nf-core modules directly from nf-core in a pipeline (which is what #3083 will implement), this will possibly cause subworkflows to break if an updated module is used.

awgymer commented 1 month ago

So the only way in which we could test a subworkflow is to have a duplicate of the nf-core module? I am wondering if we could find an alternative, but I can't think of one right now.

If #3083 is accepted you could set it up so that your tests install the subworkflow and then run the tests. This would of course necessitate having a pipeline type repo in your CI/CD in which to install the subworkflow into.

this will possibly cause subworkflows to break if an updated module is used

As it stands this sort of affects nf-core/modules already. If you update a module and change its input/output in a breaking way, it will break any subworkflow using it (of course this will be flagged by CI/CD).