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

Conda: Support .lock file extensions. #5583

Open
ewels opened this issue Dec 6, 2024 · 0 comments
Open

Conda: Support .lock file extensions. #5583

ewels opened this issue Dec 6, 2024 · 0 comments

Comments

@ewels
Copy link
Member

ewels commented Dec 6, 2024

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:

@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:

  1. 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)
  2. 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.

See also #5582 about handling remote files.

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

2 participants