Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need 'template' support similar to PyTeal #52

Closed
pbennett opened this issue Jan 27, 2023 · 2 comments
Closed

Need 'template' support similar to PyTeal #52

pbennett opened this issue Jan 27, 2023 · 2 comments
Labels
feature request Request a new feature or change to an existing one

Comments

@pbennett
Copy link

My infra works with raw teal, so I use beaker, pyteal, etc. to generate TEAL that's checked-in and built directly into binaries or part of a bootstrapping process.
That raw teal includes 'template' substitutions that are replaced with values specific to each environment (testnet / mainnet contract IDs, or parameter values for eg).

In PyTeal, a reference to a templated int (same w/ Bytes) might be like:
xxx.store( Itob(Tmpl.Int("TMPL_XXX")) )
which might become:

int TMPL_XXXX
itob
store 50

in TEAL. My code converts that prior to compilation, replacing the templates in descending length order.

This is one of the showstoppers for me in using Tealish.

@fergalwalsh
Copy link
Collaborator

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
Copy link
Author

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.

@fergalwalsh fergalwalsh added the feature request Request a new feature or change to an existing one label Feb 3, 2023
@tinymanorg tinymanorg locked and limited conversation to collaborators Feb 3, 2023
@fergalwalsh fergalwalsh converted this issue into discussion #69 Feb 3, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
feature request Request a new feature or change to an existing one
Projects
None yet
Development

No branches or pull requests

2 participants