Closed ImagoXV closed 2 months ago
It's no version problem It works fine when running with docker But not with singularity What could be involved
When inside the docker container :
> library(phyloseq)
>
When inside singularity
> library(phyloseq)
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/imago/R/x86_64-pc-linux-gnu-library/4.3/stringi/libs/stringi.so':
libicui18n.so.70: cannot open shared object file: No such file or directory
>
Singularity is modifying environment variables
$ singularity --verbose shell nanoasv
VERBOSE: Setting HOME=/home/imago
VERBOSE: Setting PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
which of course reults in looking for files outside of the container
Error: package or namespace load failed for ‘phyloseq’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/imago/R/x86_64-pc-linux-gnu-library/4.3/stringi/libs/stringi.so':
libicui18n.so.70: cannot open shared object file: No such file or directory
Why you do this. The whole purpose of your existence IS NOT TO USE FILES FROM OUTSIDE OMG
$ singularity shell --containall nanoasv
The problem with --containall is that singularity stops to mount the filesystem as well. So no access to data. So R works fine, phyloseq package gets loaded without troubles.
The following allows to use R and phyloseq but has no access to the data.
singularity run --containall nanoasv
seems to solve to solve the problem. EDIT: No it does not. It runs fine with shell, but not as nanoasv. I still can't find how to make it run properly
But I don't want to add arguments to my singularity run function.
I want to be able to run my singularity image as an exxecutable. The options being only for nanoasv and not to avoid singularity to do stupid shit
singularity run --no-home nanoasv [...]
Somehow works. But you need to have the fles exactly in the same directory as the nanoasv.sif file I don't want that.
The problem was definitly identified by other users online
Which led to its resolution I guess here :
https://github.com/apptainer/singularity/pull/6224
Now I'll figure out to maki it work smoothly
Ok, I'm getting closer, I identified the point where docker and singularity diverge in the case of my problem
When running R inside the docker container :
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
When running with singularity --containall
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
[3] "/usr/lib/R/library"
When running singularity run classic way
> .libPaths()
[1] "/home/imago/R/x86_64-pc-linux-gnu-library/4.3"
[2] "/usr/local/lib/R/site-library"
[3] "/usr/lib/R/site-library"
[4] "/usr/lib/R/library"
So maybe, a dumb workaround would be to change these values inside of R so I'm sure it will look for the apropriate package at the expected location. If I can't find how not why those values are injected. N=Can't find how to avoid injection while keeping open access to local file system
So I added the following line to the Rscript
.libPaths(c("/usr/local/lib/R/site-library","/usr/lib/R/site-library","/usr/lib/R/library"))
Which allows
> .libPaths(c("/usr/local/lib/R/site-library","/usr/lib/R/site-library","/usr/lib/R/library"))
> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library" "/usr/lib/R/library"
YES
Worked(around) !
Something might have changed.
I'm pretty sure that's because of ubuntu:latest
Gotta change for ubuntu 22.04
I'm sure at some point it was specified. IDK what happened