Awesome. When you say build a

binary

dependency, you mean something like a

python_binary

to build a

.pex

file for it, right? For 5 with leveraging Docker’s cache, depending on how Docker’s caching works, there’s a mechanism you can use to leverage it. If Docker’s caching is append-only, rather than mutating the cache, there’s a way to hook into that, which we can help with as an optimization. (We’re still working on a mechanism to use tool’s caches when they are mutable.) I think I’d recommend this workflow: 1. Add a

docker

target type. At first, you might want to only have

DockerSources

as a field, and we can add other fields like

dependencies

later. This target is what you use to give metadata about your

Dockerfile

2. Hook into the

package

goal to run

docker build

on your

docker

target. See https://www.pantsbuild.org/docs/plugins-package-goal for a guide. At this point, all you are doing is running Docker. You’ll use

BinaryPaths

to find

Docker

, use

Get(SourceFiles, SourceFilesRequest)

to get the dockerfile present, and then use

Process

to run your subprocess. 3. Augment your target type to allow dependencies on binary targets. When those are used, your plugin will run the equivalent of

./pants package

(formerly

./pants binary

), and then you can use the result and include it in your Docker subprocess. This is how the new

archive

target type works; you’ll be able to copy and paste most of

pants/core/target_types.py

4. Augment your target type to also allow depending on loose files/resources. This will also be very similar to the

archive

target type. How does that sound?