I have a Docker image that fails to find Perl dependencies when run from the command line, but runs fine if I execute the same command from an interactive prompt in the Docker image.
I am running this image as follows from the command line:
docker run --rm -v /srv/data:/srv/data wgs_binning -i /srv/data/contigs.fna.gz -c /srv/data/coverage.tsv -o /srv/data/test_binning
This results in the following issue related to Perl dependencies:
Can't locate LWP/Simple.pm in @INC (you may need to install the LWP::Simple module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at /opt/conda/bin/run_MaxBin.pl line 4. BEGIN failed--compilation aborted at /opt/conda/bin/run_MaxBin.pl line 4.
I am accessing an interactive prompt of the Docker image with:
docker run --rm -it -v /srv/data:/srv/data --entrypoint bash wgs_binning
If I run the following in the interactive prompt, it runs without issue:
python3 binning -i /srv/data/contigs.fna.gz -c /srv/data/coverage.tsv -o /srv/data/test_binning
The entry point of my Dockerfile is ENTRYPOINT ["python3", "binning"] so I would have expected the behaviour in these two situations to be identical.
Is there some sort of pathing or permission difference between running a command on the command line versus on an interactive prompt?
The offending program here is called MaxBin and this is install in the Dockerfile via mamba. Not sure this should matter, but perhaps there is an interaction between the conda/mamba environment that differs under the two scenarios I outlined?
Thanks, Donovan
Full Dockerfile as as follows:
FROM python:3.12.4-slim-bookworm
LABEL description="Recover MAGs from assembled contigs using UniteM."
LABEL maintainer="Donovan Parks <donovan@koonkie.com>"
LABEL version="0.1.0"
# install additional Linux dependencies
RUN apt-get update -y -m && \
DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends --no-install-suggests -y \
wget && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
# install Mambaforge
RUN wget --quiet https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh -O ~/mambaforge.sh && \
/bin/bash ~/mambaforge.sh -b -p /opt/conda && \
rm ~/mambaforge.sh
# Put mamba in path so we can use mamba commands
ENV PATH="${PATH}:/opt/conda/bin"
# initialize shell with conda
RUN /opt/conda/bin/conda init bash
# install bioinformatics tools with mamba where available
RUN mamba install -c bioconda \
metabat2=2.15 \
maxbin2=2.2.7 \
&& mamba clean --all
# activate the virtual environment and install dependencies
WORKDIR /wgs_pipeline/dependencies
RUN /opt/conda/bin/pip install --upgrade pip
COPY KBL/requirements.txt requirements.txt
RUN /opt/conda/bin/pip install -r requirements.txt unitem==1.2.6 checkm-genome==1.2.3
# install KBL and WPL libraries
WORKDIR /wgs_pipeline/libraries
COPY wgs_pipeline/wgs_pipeline/wpl/*.py ./wpl/
COPY KBL/kbl/*.py ./kbl/
COPY KBL/kbl/external/*.py ./kbl/external/
# add KBL and WPL libraries to Python path
ENV PYTHONPATH="/wgs_pipeline"
ENV PYTHONPATH="/wgs_pipeline/libraries:${PYTHONPATH}"
# copy WGS application script(s)
WORKDIR /wgs_pipeline/apps
COPY wgs_pipeline/wgs_pipeline/apps/binning/*.py ./binning/
ENTRYPOINT ["python3", "binning"]
Look at the environment variables in both cases (maybe just running perl -V). I bet the working case has settings for PERL5LIB and the non-working case doesn't. As someone already noted, an interactive session uses various dot files that may be setting environment variables that impact this.
And, you can pass environment variables to the process inside docker with --env or --env-file.