This proposal considers modifying the way Guild applies flag values to Python script globals. Guild’s current method is to modify the Python module AST at runtime to assign flag values to the applicable variables/state in the Python VM at runtime. This proposal considers re-writing the applicable Python module source code when it initializes the run directory. The re-written Python source code files would contain the applicable flag values.
This proposal is under development
Guild’s method of setting flag values for Python global begs two questions that are important to users:
- How are the values applied to the source code at runtime?
- In retrospect, what code ran for a run?
This information can be implied from the record but is not explicitly reflected anywhere.
This arrangement undermines Guild’s mandate to create a clear, interprettable record of what was run.
Rather than inject flag values at runtime, Guild will modify applicable Python source code files to reflect the current set of flag values.
Consider this simple example.
# test.py x = 1 print(x)
For a command:
guild run test.py x=2
Guild would re-write the file
test.py as follows:
# test.py x = 2 print(x)
Or, perhaps with annotations:
# test.py x = 2 # flag x=2 print(x)
How does a user know if a change to source code is from a project origin or from a Guild change?
- Guild could use comments to denote that it made the change.
- Guild could write the modified source files to an empty directory that is then included in the Python path, ahead of the run directory.
Both of these approaches would solve the problem and make it clear what changes Guild is making for a run. Option 2 provides a clean separation of Guild mods to project source code. However, it makes it more difficult to diff run source code to project source code.
Option 1 adds complexity to the re-write algorithm but otherwise solves the problem.
Re-starting a run with different flags modifies source code.
This is not really a problem as the user has the option of using current project source code on a restart anyway. Guild does not strictly lock runs after they finish (regardless of exit status).