Make container/conda profiles more strict #866
Conversation
nf_core/pipeline-template/{{cookiecutter.name_noslash}}/nextflow.config
Outdated
Show resolved
Hide resolved
|
Was doing that in Sarek, works well, I think I removed it with the lastest sync |
|
Should I post in the slack channel with a @channel ping to make sur eit's not going to break anything for anyone (maybe they have their own strategies, for whatever reason)? I feel this sort of a big change given everyone uses these profiles... |
|
or isn't it something that we would want to take care on within the configs? at an institutional level? |
|
I don't think so. The institutional example I gave is only one example, I think it could happen in other contexts with private configs, and the names of configs we are modifying here are most descriptive of the behaviour we are defining. Unless I misunderstand? |
|
I think this needs a rebase because of additional profiles that were introduced in bbd26ab |
|
Done! Just to double check @phue - charliecloud does requires it's own 'dedicated' config (where the |
|
It used to be required to set the container environment explicitly using an |
This draft PR is to act as a PoC for making container/conda profiles more strict as to what is being inherited.
Originally described on slack.
The purpose of the change is to ensure that, given nextflow inheritance rules, the final container/conda profile specified in
-profileshould be used. Currentlycondais given a lower priority over containers, and if a container profile is specified somewhere in the profile list it will override the use ofcondaregardless ifcondais specified last.Use case: a user wants to run a pipeline using their institutional profile, where e.g. singularity is being used by default within the profile. However the user is test/developing a pipeline and would rather use conda.
PR checklist
CHANGELOG.mdis updateddocsis updated