Zenith: How to use shell command with entrypoint? #6436
-
|
I'm trying to understand how the dagger-shell command works with entrypoints. Consider the following example: ...
@function
def debug() -> dagger.Container:
return (
dag.container()
.from_("debian:bookworm")
.with_exec(["apt-get", "update"])
.with_exec(["apt-get", "install", "-y", "python3", "python3-venv"])
.with_exec(["python3", "-m", "venv", "/venv"])
.with_new_file(
"/usr/bin/local/entrypoint.sh",
contents=f"""
!#/bin/sh
source /venv/bin/activate
exec "$@"
""",
permissions=0o755,
)
.with_entrypoint(["/usr/bin/local/entrypoint.sh"])
.with_default_args(["/bin/bash"])
)A common use case is to source an environment before entering the shell. In a Dockerfile, you would write: ...
ENTRYPOINT ["/usr/bin/local/entrypoint.sh"]
CMD ["/bin/bash"]This sources the environment before handing over to bash. However, when you run the above function using dagger shell debug, the command constructs the container, executes the entrypoint, and then exits, leaving no interactive shell prompt. What am I missing? Workaround for now: Place the entrypoint in |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
There's an issue in shell with reporting errors. So a failed execution of the entrypoint just exits without a proper non-zero return code and error message. In your case, you can debug manually with ❯ dagger shell debug --entrypoint=bash
root@urjt6mj2624m0:/# /usr/bin/local/entrypoint.sh /bin/bash
/usr/bin/local/entrypoint.sh: line 2: !#/bin/sh: No such file or directory
root@urjt6mj2624m0:/# which sh
/usr/bin/shThis explains why you're not able to enter shell, but you don't actually need to source the venv like that. For the virtual env, the only thing that you need is import dagger
from dagger import dag, function
@function
def debug() -> dagger.Container:
return (
dag.container()
.from_("debian:bookworm")
.with_exec(["apt-get", "update"])
.with_exec(["apt-get", "install", "-y", "python3", "python3-venv"])
.with_exec(["python3", "-m", "venv", "/venv"])
.with_env_variable("VIRTUAL_ENV", "/venv")
.with_env_variable("PATH", "$VIRTUAL_ENV/bin:$PATH", expand=True)
)The ❯ dagger shell debug
root@ffli2auhp921u:/# which python
/venv/bin/python
root@ffli2auhp921u:/# which pip
/venv/bin/pip |
Beta Was this translation helpful? Give feedback.
-
|
For more information on this, check this article: Elegantly activating a virtualenv in a Dockerfile |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, the command not returning an error misled me. I was finally able to get it to work. The error in the hashbang was just a typo when I wrote the ticket, nevertheless a good catch. There was another issue with the sourced script. Thanks for pointing me into the right direction and showing how to debug. As for virtual environments, I'm aware of this approach. I only used it here as an example to simplify things, so I apologize for any confusion. There are other ecosystems, such as Yocto and SDKs, that require you to source some build environment setup script where the approach suggested for Python virtual environments doesn't apply. Essentially, my example translates to: ...
..with_new_file(
"/usr/bin/local/entrypoint.sh",
contents=f"""#!/bin/bash
# DO ADDITIONAL STUFF HERE, e.g. setup build environment
exec "$@"
""",
permissions=0o755,
)
.with_entrypoint(["/usr/bin/local/entrypoint.sh"])
.with_default_args(["/bin/bash"]) |
Beta Was this translation helpful? Give feedback.
There's an issue in shell with reporting errors. So a failed execution of the entrypoint just exits without a proper non-zero return code and error message. In your case, you can debug manually with
--entrypoint, which forces the command to use:This explains why you're not able to enter shell, but you don't actually need to source the venv like that. For the virtual env, the only thing that you need is
PATH=/venv/bin:$PATH. You can also setVIRTUAL_ENV=/venvsince some tool…