Say I have a

requirements.txt

file. Using the

python_requirements

target I can turn that into a bunch of generated

python_requirement

targets. Now, if I change one of the requirements in

requirements.txt

, is there a way to single out that

python_requirement

target so I don’t have to rebuild everything that depends on any generated target from those requirements, but only the one that was actually changed?

I’m using the

--changed-since

option, and that treats the whole file as a single unit, which is a bit unfortunate (I have another target gen using another kind of input source file)

Hmm… I realise that this is perhaps not really possible, but that I should instead split my input source files into smaller units, and source them with a glob instead…

OK, so a bit of my confusion may come from this fact:

$ ./pants dependees mirror/images.txt 
09:30:53.15 [ERROR] 1 Exception encountered:

  ResolveError: No owning targets could be found for the file `mirror/images.txt`.

Please check that there is a BUILD file in the parent directory mirror with a target whose `sources` field includes the file. See <https://www.pantsbuild.org/v2.9/docs/targets> for more information on target definitions.

You may want to run `./pants tailor` to autogenerate your BUILD files. See <https://www.pantsbuild.org/v2.9/docs/create-initial-build-files>.

If you would like to ignore un-owned files, please pass `--owners-not-found-behavior=ignore`.

$ ./pants peek mirror:mirror
[
  {
    "address": "mirror:mirror",
    "target_type": "docker_mirror_images",
    "description": null,
    "overrides": {},
    "source_raw": "images.txt",
    "sources": [
      "mirror/images.txt"
    ],
    "tags": null
  }
]

From what

peek

tells me, my target gen

docker_mirror_images

has

mirror/images.txt

as its sources, so why do I get the unowned file error above.. ?

investigating…

Ah, the generator target itself is excluded… hmm… OK, I think I recall something regarding this from the generator discussions, so I understand it is due to not producing confusing output with

list ::

etc…

So it’s a gotcha that target generators that has input source(s), need to also generate targets for those inputs, and add dependencies to those as needed, then, I guess.. makes kind of sense to be able to control the behaviour here on a per generator basis. (would love some docs on target generators 😁 unless I’ve missed them)

OK - so that solved it.

Used the

python_requirement

as example, as it has the same semantics from a user perspective.