Can a codegen target overwrite a 'real' target? Context: I want to bake a hash of (some of a) package's contents into a package. I currently have this target graph:

everything_else...
     /|\
      |
python_sources() 
/|\        /|\
 |          |
 |     hash_generator()
 |         /|\
 |          |
package_target()

(a dependency of) my

python_sources()

provides a

set_hash(hash)

and

get_hash()

function. my

hash_generator()

does a codgen, and outputs some code that calls

set_hash(12345)

then the

package_target()

imports both at runtime and magically gets its hash set. This then means the tests don't depend on the

hash_generator()

target to be included, and they can just call

set_hash()

if they need to. But it doesn't feel right, and I'm considering maybe just having

get_hash(): return None

return, and then the

hash_generator

can overwrite the file with

get_hash(): return 12345

Hey @ambitious-actor-36781 - noticed you haven't got a response yet but I hope you've gotten further. If you haven't: I'm sure it's possible with enough wrestling, but I think it makes more sense to treat it as two separate things. Say you've got a

.pyt

template file, and then you've got a backend that converts that to a python_source(). That means you're not modifying - it's the same flow as any other code-generation target. And in my experience so far; being same-y with something that exists means you can do less work and get more.

Is .pyt a recognised thing?

No, it's just an easy way to differentiate from a "proper" python source 🙂 You can call it

foo.bar

, or generate it fully from code.

Ah, yeah. Not sure how that wound work. The contents of the hash are dependent on the dependees of the “root” target.

I don't quite understand. If you can already codegen, you already have all the information you need. Right? Your codegen target could say it depends on the root package, or ten other unrelated packages.

On my phone currently. Will have to re-explain later today.

👍 No worries! I'm probably missing something here.