So. rpm-ostree Treefiles define an image that you want to compose. Thing is, they have implicit dependencies on several files expected to be in the same directory as them. Some of these are completely implicit (a

passwd

file and a

group

file) and the rest are even more indirect (

*.repo

files containing the yum repo definitions for the repos declared in the Treefile). Is the right way to model this: 1. Some kind of

SourcesField

subclass that will magically attach the dependent files to the Treefile by attaching the

passwd

and

group

files and then inspecting the Treefile and the nearby

*.repo

files to work out which of those need to be attached. 2. Some kind of

Target

and/or

InferredDependencies

construct?

At first blush, this seems like a prime candidate for

dependency_inference

- which feels closer to option 1. This is a topic I wish I knew more about, but it's still the most voodoo to me, because I haven't had to write one yet. But here is one I use as a reference (getting C/C++ headers from a C source), and of course, the python ones: https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/cc/dependency_inference/rules.py https://github.com/pantsbuild/pants/tree/main/src/python/pants/backend/python/dependency_inference

Inferred dependencies are targets though, right? So I might also need a target generator of some kind?

I feel like at some point everything is a Target. files, resources, source code. You'll need some mechanism (custom target, or maybe one of the existing targets) so that Pants knows what it can look And yeah, probably a generator which is just sugar for a whole bunch of targets. For example here, while playing around, I made something that pulled in everything in this directory and all subdirs. No cleverness, no nuance: https://github.com/sureshjoshi/pants-plugins/blob/e9ffe21d0efbdc5b09b37c5e870a89ba6d663a64/helloansible/BUILD.pants#L1-L4 Now, I can play around with it in a pants-way

No, it’s work-related and very much not open source.

yea, there are few different potential approaches in this case. if you knew all the filenames statically without any additional logic, you could match them all by default in a

SourcesField

. since it sounds like some of them are only known dynamically based on the content of some of those files, you could use target generation to generate targets that match all of the files: that allows you to run

@rule

logic to locate all of the files and apply owning targets to them. because you would have parsed the files, you could generate the targets with appropriate dependencies in the first place (no inference needed) alternatively to target generation, you could require explicit targets be declared in BUILD files (or be generated by

tailor

): then dependency inference would need to come into play to find the dependencies between those targets