So, I'm thinking about the nFPM packaging backend, and I have some questions about facilitating codegen when hydrating sources. Here is a bullet list of my thoughts (background for the question) with the questions in the last couple bullet points. • An

nfpm_*_package

(deb, rpm, etc) has a series of dependencies. ◦ Many of these dependencies are

nfpm_content_file(s)

targets ▪︎

nfpm_content_file

targets contain packaging metadata like file ownership and permissions that is not available on the dependencies that actually provide the sources. ▪︎

nfpm_content_file

targets have deps on the targets that actually provide the sources (in most cases). • The packaging rule has to generate a sandbox that the nFPM tool can pull files (sources or other binaries/packages) from. • So, the rule gets the transitive deps of the

nfpm_*_package

target which gives me a flattened list of deps (the dep graph gets flattened). ◦ I pluck all of the Package targets from

TransitiveTargets.dependencies

and build the relevant packages. ◦ Next I want to hydrate all of the sources, but allow codegen to take place. ◦ Hydration + codegen requires that I know which source-types should be generated, but there is no way to infer that (A deb, rpm, etc can include basically anything). ◦ So, I either: ▪︎ Need to somehow get a list of all possible codegen types and enable all of them ▪︎ Need to add a field somewhere where the user can specify desired codegen types in BUILD files. • At first, I thought

nfpm_content_file

would be a good place to put that codegen info, but then I would have to walk the graph to figure out which deps should be codegen'd with which source types. • Second thought: *What about putting the

codegen_for

field on the

nfpm_*_packae

target?* ◦ Is this too big of a hammer? Does codegen need to be more fine-grained (only codegen for these types on these targets)?

can’t you rely on the type of source field for each dependency target? If a nfpm package depends on a

python_source

it will have the proper source field type to provide to codegen to generate it.

Oh, so grab all the types of all of the deps source fields and use that. That could probably work. I like that better. Thank you!