Need 'template' support similar to PyTeal

[tinymanorg]

Need 'template' support similar to PyTeal

[fergalwalsh]

I think there are 3 levels where template substitution can be used:

1. Tealish
2. Teal
3. Bytecode

So far I have been doing it at the bytecode level. For example in Tinyman we have logicsigs per pool. These are generated from a template and the asset ids are inserted by replacing specific bytes of the bytecode. It works this way so that the frontend can generate the final logicsig without needing to compile Teal.

I understand in your case you currently have a single PyTeal file which compiles to a single Teal file but then at assembly time you generate specific Teal files with the values before assembling.

In theory you could also replace the values in the PyTeal/Tealish before compiling to Teal but I assume there is a reason you prefer to do the replacement at the Teal level?

Supporting this would require accepting TMPL_ prefixed names in places that expect int or byes. I'd be tempted to restrict this to const declarations. E.g. const int APP_ID = TMPL_APP_ID. Would that work for you? With #49 that would result in the following Teal #define APP_ID TMPL_APP_ID.

[pbennett]

For me at least, constants would be fine as my templates are explicitly for network-specific asset and application IDs.
I also do bytecode manipulation for LSIGs in the backend, but deployed Smart-Contracts doing the same thing would also do it using the template technique as the deployed smart-contract would need to vary from network to network.
Generically, because the templates are like constants in their use - I don't see how your constant eg wouldn't work fine for pretty much all cases.

I do it at the teal level because the pyteal/beaker/tealish/.. -> TEAL compilation step is part of a 'contract build'. The output should be stable (recreating them should always compile to the same teal) and doesn't vary from environment to environment.

The output of that feeds into another repo which has those teal files as part of their build process - with the TEAL being directly compiled into the backend infra - whether for system tests (substituting just created IDs in a sandbox environment for eg) or for production with values pulled from bootstrapped data specific to each deployment.