You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to reuse my existing Dockerfiles with Modal since I don't want to maintain multiple image definitions per app. Currently, this is problematic, because Image.from_dockerfiledoesn't support at least some of the build instructions like --build-arg and --target (for multi-stage builds). I also can't find a way to specify the build context (the context_mount argument is deprecated). The documentation mentions it's "automatically inferred" --- it would be great if the docs could elaborate on how exactly is this done under the hood.
Because of that, images have to be built outside of Modal, pushed to the container registry, and then imported to Modal, which complicates local development.
The automatic package discovery is nice but it's not very transparent how exactly does it work. My guess is that Modal checks for the presence of editable dependencies in the Python environment and infers their location? Is it also looking at the current (where the app is located) package dependencies? What if there are multiple pyproject.toml files (e.g. managed a monorepo managed by uv workspaces)? It doesn't seem to work correctly with local editable dependencies.
P.S. A very solid API for defining container builds in Python can be found in Dagger
Edit: found some mentions of the Python packages auto-discovery here, looks like auto-discovery is being deprecated anyway.
The text was updated successfully, but these errors were encountered:
First of all thanks for the details issue report, much appreciated. It think as this issue encompasses more than just modal-client concerns https://modal.com/slack would be a good place to have this discussion 🙂.
it would be great if the docs could elaborate on how exactly is this done under the hood.
I agree! I'll get this actioned as I don't think it's obvious how we do this and thus can't understand if it was edge-cases where the auto-mounting would be wrong.
As to the --build-arg, you're right we don't support that. I can look at getting it supported.
As to --target, I haven't used this but it looks like a way to build a single stage in a multi-stage build. How would you want to use this within Modal, for debugging?
I have a multi-stage Dockerfile shared for a few flavors of the image. I would like to specify the stage needed for Modal applications (it would improve layers caching).
I would like to reuse my existing
Dockerfile
s with Modal since I don't want to maintain multiple image definitions per app. Currently, this is problematic, becauseImage.from_dockerfile
doesn't support at least some of the build instructions like--build-arg
and--target
(for multi-stage builds). I also can't find a way to specify the build context (thecontext_mount
argument is deprecated). The documentation mentions it's "automatically inferred" --- it would be great if the docs could elaborate on how exactly is this done under the hood.Because of that, images have to be built outside of Modal, pushed to the container registry, and then imported to Modal, which complicates local development.
The automatic package discovery is nice but it's not very transparent how exactly does it work. My guess is that Modal checks for the presence of editable dependencies in the Python environment and infers their location? Is it also looking at the current (where the app is located) package dependencies? What if there are multiple
pyproject.toml
files (e.g. managed a monorepo managed by uv workspaces)? It doesn't seem to work correctly with local editable dependencies.P.S. A very solid API for defining container builds in Python can be found in Dagger
Edit: found some mentions of the Python packages auto-discovery here, looks like auto-discovery is being deprecated anyway.
The text was updated successfully, but these errors were encountered: