[QST] Docker ENTRYPOINT not using conda environment in exec form

[pdrebello]

I am creating a custom docker image as follows:

FROM rapidsai/rapidsai-core:21.06-cuda11.0-runtime-ubuntu18.04-py3.7 WORKDIR /root COPY run.py /root/run.py

RUN source activate /opt/conda/envs/rapids

ENTRYPOINT ["python", "run.py"]

I then try to import cudf in run.py. I get error: "ModuleNotFoundError: No module named 'cudf' "

[beckernick]

Perhaps this Docker documentation may help answer your question.

Unlike the shell form, the exec form does not invoke a command shell. This means that normal shell processing does not happen. For example, ENTRYPOINT [ "echo", "$HOME" ] will not do variable substitution on $HOME. If you want shell processing then either use the shell form or execute a shell directly, for example: ENTRYPOINT [ "sh", "-c", "echo $HOME" ]. When using the exec form and executing a shell directly, as in the case for the shell form, it is the shell that is doing the environment variable expansion, not docker.

You can specify a plain string for the ENTRYPOINT and it will execute in /bin/sh -c. This form will use shell processing to substitute shell environment variables, and will ignore any CMD or docker run command line arguments. To ensure that docker stop will signal any long running ENTRYPOINT executable correctly, you need to remember to start it with exec:

ENTRYPOINT exec top -b

Keep us posted with how things work out! In the future, please make sure to include a relevant title for your Github issue.

[pdrebello]

Modified:

ENTRYPOINT ["python", "run.py"]

to

ENTRYPOINT python run.py

but continue to get the same error

[pdrebello]

Resolved by changing:

ENTRYPOINT python run.py

to

CMD python run.py

ENTRYPOINT uses '/bin/sh -c' by default. cudf now being imported. Thanks for the help!