Allow cog build and cog push to specify path to custom Dockerfile

[technillogue]

For building tiny images and modifying existing images with less pain

This is also intended as an escape hatch for when cog's dockerfile generation is inadequate. You can use cog debug as a starting point and edit that.

If this is merged, we can revert stuff like #1289. This provides for edge cases where you need a dependency to compile packages that you don't want at runtime, and various other problems.

This is also mentioned in https://github.com/replicate/cog/blob/main/pkg/config/config.go#L20

[zeke]

Hi there. Thanks for sharing your work. 👍🏼

If you think this is something that could be generally useful for others, would you be willing to write some docs explaining the rationale behind these changes and what they make possible?

[technillogue]

The main usecase for this is developing smaller images, such as https://github.com/replicate/cog-stable-diffusion/blob/syl/pget/Dockerfile

It also provides for doing this:

FROM r8.im/username/modelname@sha256:xyzxyzxyzxyz
COPY ./fixed_predict.py /src/predict.py

There are issues where you want to try small tweaks such as sprinkling in some .to("cuda") calls but would rather not redo the entire build process. Using FROM makes that easier.

To use this, all you need to do is add a Dockerfile in the working directory and not used --separate-weights.

Should I put this documentation somewhere else?

[technillogue]

@mattt, so we have a few options about configuring it

1. leave it as-is: if there's a file named Dockerfile, use that, otherwise do nothing
2. a section in cog.yaml under build
3. yet another flag

For (3) we could do cmd.Flags().Lookup("dockerfile").NoOptDefVal = "Dockerfile" so that you could either pass --dockerfile <path> or just --dockerfile.

Other reference material includes flyctl's --dockerfile string Path to a Dockerfile. Defaults to the Dockerfile in the working directory, and their behavior of using dockerfiles if present but otherwise trying to guess a buildpak for a given app.

[mattt]

@technillogue I think --dockerfile <path> is the best option. It also lets you point at multiple Dockerfiles, allowing for things like dev/prod variants, easier debugging between two versions, and monorepos with multiple models.

[mattt]

@technillogue Any idea why integration tests are failing with these changes?

Edit: Never mind, I figured it out. Pushing a fix soon.