Input packages for oci_image_build are not included as dependencies for the target about pants-backends HOT 3 OPEN

Hmm, interesting! I think this is mostly a display issue, will have to look more closely. Pants makes some assumptions about fields being (somewhat) unique -- in particular, that there is only one Dependencies field etc. Some of my targets have two, because I think the UX of a separate field for the "base" image is preferrable. I've not noticed any adverse effects in practice, but I hadn't considered this aspect.

from pants-backends.

It's the same in the examples in this repo:

pants-backends main
 ❯ pants dependencies //examples/oci:oci
examples/oci:python3-d11#latest

 ❯ pants peek //examples/oci:oci
[
  {
    "address": "examples/oci:oci",
    "target_type": "oci_image_build",
    "args": null,
    "base": [
      ":python3-d11#latest"
    ],
    "commands": null,
    "dependencies": [
      "examples/oci:python3-d11#latest"
    ],
    "description": null,
    "entrypoint": null,
    "env": null,
    "layers_raw": null,
    "output_path": null,
    "packages_raw": [
      ":example"
    ],
    "repository": "harbor.sbg.dev/test/pants-plugin-oci-example",
    "tag": "latest",
    "tags": null,
    "terminal": false
  }
]

How does it know when it needs to rebuild the image when the pex is rebuilt? Do you pick that out manually, or just run everything?

from pants-backends.

Hmm, interesting! I think this is mostly a display issue, will have to look more closely. Pants makes some assumptions about fields being (somewhat) unique -- in particular, that there is only one Dependencies field etc. Some of my targets have two, because I think the UX of a separate field for the "base" image is preferrable. I've not noticed any adverse effects in practice, but I hadn't considered this aspect.

FYI I worked around this for my case by using oci_layer, putting the packages in there and adding that instead to oci_image_build, then everything behaves as expected with dependencies.

from pants-backends.