Fix mhcflurry docker permission problem

[skrakau]

When running mhcflurry in combination with the docker profile, it tries to create a dir /.local/ to download the MHCflurry models, which causes an "permission denied" error (see #51).

To fix this problem I changed the MHCFLURRY_DATA_DIR and MHCFLURRY_DOWNLOADS_CURRENT_RELEASE environment variables within the precess peptidePrediction. I guess this could also be changed in the Dockerfile, but thought in the process this might be more intuitive. Or what do you think?

To get this working, one needs for some reason to specify the MHCflurry release for which to download the models. Thus the MHCFLURRY_DOWNLOADS_CURRENT_RELEASE environment variable would need to get updated as well, when MHCflurry will be updated in the future (which is a bit unfortunate, since it's a bit error prone, but I didn't see a different solution).

The different versions of the MHCflurry python/conda packages and github tags were a bit confusing. I obtained the specified version 1.4.0 by manually installing mhcflurry 1.4.3 and then running 'mhcflurry-downloads fetch models_class1' (which writes out the used version for the model download) .

PR checklist

• This comment contains a description of changes (with reason)
• If you've fixed a bug or added code that should be tested, add tests!
• If necessary, also make a PR on the nf-core/epitopeprediction branch on the nf-core/test-datasets repo
• Ensure the test suite passes (nextflow run . -profile test,docker).
• Make sure your code lints (nf-core lint .).
• Documentation in docs is updated
• CHANGELOG.md is updated
• README.md is updated

Learn more about contributing: https://github.com/nf-core/epitopeprediction/tree/master/.github/CONTRIBUTING.md

[christopher-mohr]

I just had a look at the GitHub page of MHCflurry. The described common issue seems to be the one you noticed I guess?

[skrakau]

You mean the HTTP connection issue? I wouldn't think so. I think it is a permission problem, because it can't create the folder /.local in the root directory of the docker container, which it tries to create before downloading the models (not sure why it doesn't occur with singularity on the cfc, maybe it uses some scratch directory or it's a difference between docker and singularity). But when manually creating it before and adjusting the permissions or when changing the directory with the environment variable, mhcflurry-downloads fetch just works.

[christopher-mohr]

@skrakau I searched in the nf-core slack and actually mhcquant had exactly the same issue. As far as I could see this seems to be the problem and solution:

commented that part out from the nextflow.config file: docker.runOptions = '-u $(id -u):$(id -g)' and rerunning with -profile test,docker and it succeeded

@nf-core/core would that still be the best solution in this case?

[skrakau]

Hi @christopher-mohr, I also asked about this issue in the nf-core help channel. My conclusion would be:

• uncommenting the line docker.runOptions = '-u \$(id -u):\$(id -g)' should be avoided, since it addresses some other issues (Add docker.runOptions to avoid memory swap error tools#351)
• in general, writing and reading to the host HOME directory, which happens when using Singularity (and maybe Docker without Mac), should be avoided, since it can cause reproducibility issues
• writing to the work directory should be preferred over a location within the container

Thus, since it is actually possible to change this behaviour using the mhcflurry environment variables, I would vote for this solution, even if it forces us to additionally take care of the specified release version etc..

[christopher-mohr]

Hi @christopher-mohr, I also asked about this issue in the nf-core help channel. My conclusion would be:

• uncommenting the line docker.runOptions = '-u \$(id -u):\$(id -g)' should be avoided, since it addresses some other issues (nf-core/tools#351)
• in general, writing and reading to the host HOME directory, which happens when using Singularity (and maybe Docker without Mac), should be avoided, since it can cause reproducibility issues
• writing to the work directory should be preferred over a location within the container

Thus, since it is actually possible to change this behaviour using the mhcflurry environment variables, I would vote for this solution, even if it forces us to additionally take care of the specified release version etc..

I totally agree. Let's go with this solution for now 👍 .

[christopher-mohr]

LGTM! I would suggest to merge it after the template merge has been completed.