spy: Instructions file for Codex

SPy Language - Dev Reference

Common Commands

• When running tests, always use the venv: e.g. `./venv/bin/pytest'
• Run all tests: pytest
• Run single test: pytest spy/tests/path/to/test_file.py::TestClass::test_function
• Run backend-specific tests: pytest -m interp or -m C or -m doppler
• Type checking: mypy

Compile SPy Code

spy your_file.spy                 # Execute (default)
spy build your_file.spy           # Compile to executable
spy build -x your_file.spy        # Compile to executable AND execute
spy --help                        # To see other commands to inspect the pipeline

When/how to run tests

The full test suite is slow. When you work on a feature with a limited/precise scope, run just the tests relevant to the specific feature and/or the files that you are modifying (use your own judgment).

When you want to run tests/compiler tests for a whole file and/or for the whole dir AND the file takes many seconds to run (e.g. if it contains many tests), prefer to run them backend-by-backend: interp tests are the fastest and catch most of the problems; doppler tests are a bit slower and catch doppler-specific tests; C backend are slowest and should be run only at the end.

So, if you decide to run all the tests for the file test_foo.py, do this:

1. pytest test_foo.py -m interp
2. pytest test_foo.py -m doppler
3. pytest test_foo.py -m C

Beware that come test files define their own "extra" backends.

If the test file is very short and it's quick to run, feel free to run with all backends in one go.

If you modify something which is likely to impact everything, a good smoke test is test_basic.py: run it in isolation before running the whole test suite.

Under normal development it is not necessary to run the full test suite before each commit, it is fine to run it only to make sure that the branch is ready. However, if you do whole-program modifications which are likely to break things "everywhere", then feel free to run it more often. Use your own judgment.