-
Notifications
You must be signed in to change notification settings - Fork 759
Description
The conda process takes a string input that can be either one or more package names, or a conda environment / lock file. To determine which of these two the string is, we check the file extension:
nextflow/modules/nextflow/src/main/groovy/nextflow/conda/CondaCache.groovy
Lines 160 to 167 in 5c5a810
| @PackageScope | |
| boolean isYamlFilePath(String str) { | |
| (str.endsWith('.yml') || str.endsWith('.yaml')) && !str.contains('\n') | |
| } | |
| boolean isTextFilePath(String str) { | |
| str.endsWith('.txt') && !str.contains('\n') | |
| } |
This generally works well as until now almost all usage has been with files called environment.yml, by convention. However, since Wave has started supporting Conda lock files, this convention has become weaker. Wave itself generates downloads called condalock (no extension) and the Conda ecosystem often uses .lock file extensions by loose convention. These are interpreted as package names by Nextflow and the Conda environment resolution fails.
Instead I'd propose one of two different approaches:
- Try to match the
condastring against local file paths, treat as package names only if no local files match (eg. accept any file extension) - Explicitly add support for
*.lockandcondalockfile names.
Originally raised by @pinin4fjords in #5453 - see original issue for examples of current failure / error messages. Splitting that issue into two to keep discussion focussed.
See also #5582 about handling remote files.