Peter Baumgartner

> So publishing the cache image to the registry, but keeping the image local? I hadn't considered that option, but it would work. Although it probably makes sense _not_ to...

> Would there still be an ask to make the workflow @ekcasey mentioned? (using/publishing a cache image in a registry, while having the app image be a local docker daemon...

@dfreilich there's still an issue here that `--cache-image` *requires* the `--publish` flag currently. Would you like me to create a new issue for that or adjust this one accordingly.

My issue is that: 1. I'd like to use `--cache-image` to speed up future builds 2. Using `--cache-image` requires `--publish` 3. My workflow requires me to work with the image...

@natalieparellano What would using a cache volume look like? I see the `--volume` flag, but I'm not sure where I'd mount it. Based on what you're saying, [for my use...

> though I'd be curious to know why the cache volume needs to be uploaded. Is it being shared across builds? yeah, exactly. I'm using ephemeral build infrastructure (AWS Codebuild),...

It'd be great if the buidpack could leverage `pyproject.toml` to make this determination. PEP-518 already provides a standard way to define [a build system](https://www.python.org/dev/peps/pep-0518/#build-system-table), but Heroku could leverage its own...

If the existing info is too vague, a `[tool.heroku]` table could be used in `pyproject.toml` to define Heroku-specific values https://www.python.org/dev/peps/pep-0518/#tool-table

> Longer term do we see runtime.txt being superceded by something else (eg #932)? Yes, please! `pyproject.toml` is the blessed place to do stuff like this. I think https://github.com/heroku/heroku-buildpack-python/issues/932#issuecomment-697216718 is...

This is a good list. My first choice would be to support **B** only. Having a cascading list of places to try is clever/convenient, but I think makes things more...