Container.From should ignore image entrypoint by default

[shykes]

Problem

As discussed on Discord:

I find myself wishing that we did not honor OCI image entrypoints by default...
I would much rather know that, by default, From("foo").WithExec("bar") will always actually execute the binary "bar" in the image "foo", unless I specifically tell Dagger that I care what the image author put in the entrypoint (most of the time I don't).

Kind of like the way Kubernetes manifest ignores a bunch of fields in the docker image, and just makes you re-write them in the kub config. At the time it irked me, but now I get it. Clean slate. And more control over the overall experience for the wrapping tool (then: kube. now: dagger)

@vito added:

I struggled with this for a while in Bass, since there the syntax is ($ go build --foo) and typing ($ build --foo) because you know the entrypoint is go just felt nonsensical. I eventually had to add support for ENTRYPOINT/CMD to support publishing images, but had to square their semantics with everything else.
https://github.com/vito/bass/releases/tag/v0.12.0 Ctrl+F "Entrypoint" if you're curious to see the direction I went

Solution

Change the behavior of Container.From to not honor the image entrypoint by default. Make this configurable with a flag, to explicitly ask for it.

Or, alternatively, deprecate the support for entrypoint completely, except by raw inspection of the OCI image data (which we should support, by the way).

[vito]

Just a note: we have withExec(skipEntrypoint: true) already, so this could just be tantamount to flipping the default and adding a useEntrypoint: true for anything that needs the old behavior.

...and then dealing with the fallout. 💥

[helderco]

Yeah, I think doing this in withExec is better. This way the entrypoint is still available if you need it, but not in the way if you don't.

[helderco]

Draft submitted, but it's an alternative solution to the one suggested in this issue, based on the above comments:

• 💥 api: skip entrypoints by default in withExec #7136

Just something easy to take a breather 🙂 Doing bits on the side, but if there's no consensus on the solution it's not worth it to continue. So requesting feedback on that.

[vito]

@helderco Nice - now I guess the question is when we pull the trigger. Maybe we should just get it over with? Doesn't seem like we gain much by waiting. 😬

Maybe we need to signal boost this decision to get more community input + spread awareness?