Basic Project Setup + Migrating Code from PySDK PR #298

[tzaffi]

TEAL Blackbox in Graviton

This PR takes over from the now defunct PySDK PR #298

TLDR; Dry Run a Sequence of Inputs on Apps/LogicSigs, View Stats, and make Assertions on Behavior

Please refer to the TEAL Blackbox HowTo / README for full details

A Place to Test Our Python Repo Best Practices

Since this is a brand new repo this is a good place to set some new conventions that our other Python repos should eventually follow also. This PR does not claim to have achieved such a state (especially in light of issues #4 and #7).

Some conventions are implicitly advanced in this PR:

• no requirements.txt:
  • instead, add an extras_require (e.g. extras_require={"test": "pytest==7.1.1"},) in setup.py
  • install the test-dependencies with pip install -e.[test]
• pin internal algorand dependencies using version tags
• (For projects that use github actions) Use act to simulate github actions locally
• Use Makefile to summarize basic setup/testing commands, and incorporate these commands in CI configs
• tests should contain all unit and integration tests (as opposed to pairing *_test.py files next to the file they are testing) No longer considered a "best practice"
• test files should not be installed by default (previous bullet point makes this goal easier)
• linter configurations should go into setup.cfg whenever possible
• lint with black --check and flake8

Testing

make integration-test

Simulating Github Actions Locally (on a Mac)

make mac-gh-simulate

TODO

CI / Best Practices

• Better Demarcation of act Only Dependencies #2
• Add mypy and black and flake8 #4
• Enable Running Blackbox Testing using the Offline Version of Dryrun #6
• Illustrate running integration tests with Python 3.10 via asdf #7

Features / Improvements

• Refactor to use pysdk's DryRunTransactionResult #3
• Better assertion message for invariant predicates of 2 variables #5

Migrate Sandbox Code from PySDK and Run All Tests

Testing is cribbing off of PyTeal's "Run blackbox tests in CI" PR

• First successful docker build

  • TIME: 35 minutes
  • Compare with 35 minutes for PyTeal's first uncached build

• First cached docker build

  • TIME: 4 minutes
  • Compare with 5 minutes for a cached build on PyTeal

[michaeldiamant]

@tzaffi Thanks for tying together a number of threads to bring graviton to life. ☕

For review completeness: I'm on-board to try the proposed versioning scheme though I have lingering concerns. Since we can more freely make changes here, let's try it out and assess over time.

Rationale:

• It's possible unicode characters interact poorly with other systems (e.g. build systems) and/or are difficult to parse when not presented as emojis (e.g. git tag --list vs git --no-pager tag --list).
• The convention does not support signaling when a breaking change is made. The lack of signaling makes it harder to know when it's safe to upgrade.

[tzaffi]

@tzaffi Thanks for tying together a number of threads to bring graviton to life. ☕

For review completeness: I'm on-board to try the proposed versioning scheme though I have lingering concerns. Since we can more freely make changes here, let's try it out and assess over time.

Rationale:

• It's possible unicode characters interact poorly with other systems (e.g. build systems) and/or are difficult to parse when not presented as emojis (e.g. git tag --list vs git --no-pager tag --list).
• The convention does not support signaling when a breaking change is made. The lack of signaling makes it harder to know when it's safe to upgrade.

We should keep the new versioning scheme at least through April 1, 2022

[jasonpaulos]

Comments that didn't make sense on a particular line:

• I think the animal emoji versioning scheme only make sense if it's mapped directly to a semver version (e.g. 🐈 = 0.1.0). I think it's good marketing, but it should not replace semver and traditional versioning.
• I'm in favor of having *_test.py unit tests that live in the same directory as implementation code. They are very convenient and act as a constant reminder to write unit tests for your code.

I only shared the above two comments because the context of this repo seems to be to establish best practices for future repos. If that were not the case, my opinions on these issue would not be very strong.

[jasonpaulos]

I can accept this, though I'd suggestion development or similar instead of just test. The dev process involves more than just tests, there are also linters, formatters, etc. that help us write code.