You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 conda string against local file paths, treat as package names only if no local files match (eg. accept any file extension)
Explicitly add support for *.lock and condalock file 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.
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
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 calledcondalock
(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:
conda
string against local file paths, treat as package names only if no local files match (eg. accept any file extension)*.lock
andcondalock
file 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.
The text was updated successfully, but these errors were encountered: