Zenith: How to use shell command with entrypoint?

[skycaptain]

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 /etc/profiles.d/ and use /bin/bash --login as entrypoint. This way the environment will get sourced whenever bash is started as login shell.

[helderco]

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:

❯ 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/sh

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 set VIRTUAL_ENV=/venv since some tools use it:

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 debian:bookworm image already has bash as the default command, so:

❯ dagger shell debug
root@ffli2auhp921u:/# which python
/venv/bin/python
root@ffli2auhp921u:/# which pip
/venv/bin/pip

[helderco]

For more information on this, check this article: Elegantly activating a virtualenv in a Dockerfile

[skycaptain]

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"])