Problem

Taking inspiration from https://blog.rust-lang.org/2014/10/30/Stability.html, we'd like to prototype a feature gating mechanism like https://rustc-dev-guide.rust-lang.org/feature-gates.html. A feature gating system is one way for PyTeal to support faster velocity with fewer support guarantees while not sacrificing quality.

The story's intent is to gauge implementation + maintenance challenges associated with supporting a feature gating system in PyTeal. At the story's conclusion, we'd like to make a yes/no decision on supporting the approach as part of instituting a broader stability policy.

The feature gating mechanism does not need to mirror Rust exactly. Criteria we want to support include:

• Define a way to demarcate modules, classes, methods, and variables as experimental. Access to experimental capabilities is controlled by PyTeal release version. Only non-final (e.g. nightly builds, branch builds) versions can access experimental capabilities.
• Optionally, providing an explicit opt-in mechanism to use experimental features.

It's understood that we'll negotiate the effort while underway. We may realize some objectives are untenable. Ultimately, if the approach isn't tenable, we want to gauge where to go next.

Solution

Compiling links that may be helpful:

• https://stackoverflow.com/questions/8951787/defining-python-decorators-for-a-complete-module - The approach described here might benefit our own implementation.
• https://github.com/carta/flipper-client - Example Python feature flag library. It might help us brainstorm our own approaches.

Dependencies

Urgency