Do we use this property for anything? I'm leaning towards going the reverse direction, and officially deprecating this information.

If I recall correctly, this is information that was either used by the classic builder, or was more a "side effect" of how the classic builder (which uses docker commit) was implemented.

However, this information has been cause for confusion in many situations; inspecting an image shows multiple similar fields (e.g. Command, Env, and such). In the end, "what container was used" to produce the images config doesn't really matter. The result of that action is committed in the Image's config, and that's the only part that's used from the image. Everything else may be just noise.

No, we don't need it from the engine side. Not sure if docker-py tests check it because it's important or just happened to be a property of a committed image. If you think it's fine to deprecate, I'm all in 😅

I think there's quite some tests in docker-py testing "what they observed" at the time. Which is good because it also spotted breakage in some occasions (fields that were there but not strictly relevant for internal use).

But I also think that the containerd integration gives us a good opportunity to re-evaluate some of those. We can consider some "defendable" changes in the API (directly related to legacy implementation; no longer relevant with containerd). Of course; within reason (i.e. don't blindly just rip-out important fields)

I recall I already set the stage for that by adding some disclaimers that these fields may be empty, depending on how the image was built;

But perhaps this is the moment to start making those official deprecations (which could mean: omitting the field entirely in a future version of the API)

Also related to the above;

• api: clean-up image-inspect output #46804