-
Notifications
You must be signed in to change notification settings - Fork 417
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
fix: spark issues #378
fix: spark issues #378
Conversation
|
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.
Does this also fix @heuermh problems with the other modules?
Out of curiosity what is the difference between |
Basically it's just 2 way of doing the same thing. |
That would mean it's trying to use some files in |
Co-authored-by: Mahesh Binzer-Panchal <mahesh.binzer-panchal@nbis.se>
@nf-core/core @nf-core/sarek @heuermh @mahesh-panchal Can people test out and tell me if it 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.
To reiterate (discussion in slack):
As of today, userEmulation
includes the user runOptions as replaced, including mapping passwd and related files and home directory.
It will help in some cases, but will likely not change on e.g. macOS or if using some NSS-provider for user information (common for e.g. cluster setups and if using e.g. AD login).
It will also try to map the home directory which brings (in general) the risk of breaking stuff if something is picked up from the home directory instead of the container.
Both of these issues are not generally likely to appear and should be guarded against in the container (e.g. singularity by default maps the home directory, so it must be protected against anyway).
Overall, this is probably a slight improvement.
I should add that |
I remember Paolo saying that the code is the documentation. |
Comment from @pditommaso on Slack:
|
An alternative way of expressing it would be that spark requires special care. For the current sarek approach that's addressable, but for DSL2 I see no solution that doesn't involve maintaining a container for it. |
PR checklist
scrape_software_versions.py
nf-core lint .
).nextflow run . -profile test,docker
).docs/usage.md
is updated.docs/output.md
is updated.CHANGELOG.md
is updated.README.md
is updated (including new tool citations and authors/contributors).