Add ability to declare compatible PyTeal version in source code

[jasonpaulos]

Some of our recent discussion has prompted me to think more about how pyteal programs are dependent on compiler versions and how this dependency is represented — right now it’s handled no differently than any other python package dependency, likely in the end-user’s requirements.txt file. And since python projects often don’t pin versions, introducing significant breaking changes could be problematic for us.

A way to make this dependency stronger and more easily checked would be to introduce a "pragma compiler version" directive to pyteal source code. I still have a lot of questions about the right way to do this and if/when we’d want to do this, but I had some thoughts and wanted to share them here so I don’t forget:

• Option A: add a pragma(str) function to the pyteal package, which user code can invoke to assert the current version of pyteal satisfies some constraint. E.g.

import pyteal as pt

pt.pragma(compiler_version="0.13.1") # will fail immediately if constraints aren't met

• Option B: add a Pragma expression to the AST. This would allow subsections of the AST (especially ones provided by a pyteal library) to declare compiler version constraints. E.g.

import pyteal as pt

program = pt.Pragma(pt.Approve(), compiler_version="0.13.1")

compileTeal(program, mode=pt.Mode.Application, version=6) # will fail at compile time if constraints aren't met

• Option C: inspired by Go's major version bump policy (for better or worse), somehow put the compiler version into the package import path. E.g.

import pyteal.v0_13_1 as pt
# import will fail if version does not match currently installed one

# usage as normal

Option A seems potentially the most natural for contract authors. On the other hand, B is more practical if you import other pyteal libraries and want to make sure they all can work together on the same compiler version. These options could coexist if that seems beneficial.

Option C is a different beast. I’m not sure if we’d want to make it required or not (i.e. do you have to import pyteal.v0_13_1, or can you still import pyteal normally for unchecked usage?). Also, it’s still potentially configurable beyond pinning a single version (e.g. pyteal.v0_13 might mean v0.13.x), but configuration would be more restrictive/harder for us to implement than using a version string like the other options. If you’re a library that works on v0.12.0 through v0.14.0, how would you represent that?

edit: strikethrough option C discussion, as it seems options A & B are most appropriate at this time.

[jasonpaulos]

For options A & B, we'll want to choose a scheme that can expression version ranges. A popular & powerful option is npm's semver range scheme: https://github.com/npm/node-semver#ranges

The Python library semantic-version supports this scheme: https://python-semanticversion.readthedocs.io/en/latest/guide.html#the-npmspec-scheme