-
Notifications
You must be signed in to change notification settings - Fork 719
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 lock files #5827
base: master
Are you sure you want to change the base?
Conda lock files #5827
Conversation
Status update: This PR doesn't really do anything for us until we adopt wave. Main issue was the GitHub action can't commit the lock file back for whatever permissions issue. |
440bca1
to
70acdbe
Compare
13df3e3
to
a1bb7d5
Compare
This is pretty frickin' awesome, lock files have been on my xmas list for ages. My only questions surround how these lock files will actually get used. As-is. the We spoke on Slack about how I thought (and others disagreed) that we should also change the container directive to use what Wave spits back. I also wonder how we could make it so that people deploying via Conda could get a static environment built off the lock file? |
Couldn't get it to commit
https://github.com/nf-core/modules/blob/90b1d1bd7f9474e173abd9e4082dedb559c7542a/.github/workflows/fix-linting.yml#L62-L71 Co-authored-by: mashehu <mashehu@users.noreply.github.com>
bfc0973
to
de2fdf7
Compare
@adamrtalbot raises the excellent point that lock files will be architecture-specific. So maybe what we need is actually a conda-lock-amd64.txt, conda-lock-arm64.txt? Then workflows would need to be run with architecture-specific configurations referencing these? |
Can you embed multiple architectures in a lock file? The docs kinda say you can: https://github.com/conda/conda-lock?tab=readme-ov-file#platform-specification |
YAAAAS!
Good man. We would probably want to put them in the environment.yml, given that cross-platform compatibility will vary. |
- name: Run conda-lock | ||
run: | | ||
rm --force "${{steps.lockfile-name.outputs.result}}" | ||
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind lock --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I tested why the lock file didn't work, and I think it's because of the default unified lock files. To get a lock file compatible with Nextflow (which just does like this), you have to render it to a platform specific one:
conda-lock render -p osx-64
Rendering lockfile(s) for osx-64...
- Install lock using : conda create --name YOURENV --file conda-osx-64.lock
We can also just do:
conda-lock --kind explicit -f environment.yml
... which automatically renders to all the specified platforms.
In any case, for nextflow as-is, we will need platform-specific lockfiles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! I didn't really want to have 4+ lock files floating around. I didn't know this was a possibility, great find!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid we're stuck with those 4 lock files, unless we do that rendering dynamically somehow.
@adamrtalbot unfortunately I just discovered that the reason @edmundmiller 's new conda declaration didn't work is probably because of unified configs. So absent a fix to Nextflow we'll be needing platform-specific ones. Edit: Paolo nixed my idea for supporting unified lock files. So we are definitely limited to the platform-specific ones. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So basically I think we'll need to do like this
- name: Run conda-lock | ||
run: | | ||
rm --force "${{steps.lockfile-name.outputs.result}}" | ||
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind lock --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind lock --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}" | |
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind explicit --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}" | |
mv conda-linux-64.lock conda-lock-linux-64.yml |
Nextflow needs it to be a .yml, but use of --kind explicit
means we get .lock files, so we'll need to do some file renaming.
Platforms should probably be set in the environment.ymls actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just do...
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind lock --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}" | |
conda-lock lock $MAMBA --file "${{ matrix.files }}" --kind lock --platform linux-64 --lockfile "${{steps.lockfile-name.outputs.result}}".yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't look like that works 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The explicit
thing is important. It makes you a lock file for each platform which is consumable by conda env create
, and therefore by Nextflow.
But by doing explicit
you lose control over the naming of the multiple outputs, and Nextflow needs .yml
, hence the rename hack I suggested.
git config push.default upstream | ||
git add . | ||
git status | ||
git commit -m "[automated] autogenerated conda-lock file" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git commit -m "[automated] autogenerated conda-lock file" | |
git commit -m "[automated] autogenerated conda-lock files" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should just be a single commit per lock file I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One lock file per platform
@@ -2,7 +2,7 @@ process BOWTIE2_ALIGN { | |||
tag "$meta.id" | |||
label 'process_high' | |||
|
|||
conda "${moduleDir}/environment.yml" | |||
conda "${moduleDir}/conda-lock.yml" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conda "${moduleDir}/conda-lock.yml" | |
conda "${moduleDir}/conda-lock-linux-64.yml" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'm obviously not proposing we actually change modules for platform specificity, just illustrating).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think tracking them at this point might keep us sane though 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the lock files will be platform specific they can't go directly on the modules. I think we'd need platform-specific configs at the workflow level that referenced all the lockfiles.
@@ -15,3 +15,4 @@ __pycache__ | |||
*.pyo | |||
*.pyc | |||
.github/renovate.json5 | |||
**/conda-lock.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
**/conda-lock.yml | |
**/conda-lock*.yml |
Closes #2193
Follow up to #4080. This will add conda lock files whenever the environment.yml gets updated, and then pass that to wave.