This will come up a bunch. Should we create separate "base images" for building and runtime?

As far as I understand that's not possible without using some extensions. We could add dockerfile-x though and move the builder and runner image definitions to a common Dockerfile referenced by the per-service Dockerfiles.

I have gone with a merged Dockerfile with ARGs for bin and port. Might not be flexible enough for us in the end, but it might be (same will work fine for the ntx-builder image).

Lets see how it goes. I don't like that it assumes the binaries are the same and can be coupled like this.

I think what I was assuming originally is that we would publish build and runtime base images. I don't understand why that isn't possible; isn't that how

FROM rust:1.93-slim-bookworm AS chef

exist?

IIRC that requires the base image to exist in a registry

I would really like if we could get rid of these. They're a pain to maintain.

I guess this could be done in tandem with removing Debian packages once we move to docker ourselves?

I think I saw a comment from @Mirko-von-Leipzig regarding naming somewhere: it does feel strange to have both miden-node-validator and miden-validator crates.

One potential option is to have both library and binary targets in the miden-node-validator crate - but I'm not sure if that's a good idea.

I have renamed the lib crate to miden-validator-core. The -core suffix seems to be used in the ecosystem. Prefer -lib but doesn't seem to be as popular. cc @Mirko-von-Leipzig

An alternate suggestion is to have both crate library and binary be miden-validator. The only downside is that the main entrypoint cannot live outside the crate, so we would have either have to move the entire create into bins, or move main out into the crate