Python supports various arguments to modify the interpreter's behavior: https://docs.python.org/3/using/cmdline.html

Today, however, user programs don't have a way to set these. By the time user code runs, the interpreter is already started and they can't change them. Working around this in user space is borderline impossible (they would have to re-exec, but somehow preserve various things the bootstrap did).

To fix this, lets add an interpreter_args attribute. It is a list of strings.

Since there's several sources of args passed to the interpreter, the ordering will be:

1. bootstrap computed args (right now a special -X value)
2. The target's interpreter_args attribute (the attr in this FR)
3. Args set by an outer environment variable (as proposed in the PR to aid debugging)
4. stage2 bootstrap path
5. Any additional args from the environment ($@)

For the initial implementation, the values are just inserted as is.

Some open questions to think about:

Should the attribute support various expansions? The three types I can think of are:

1. make vars expansion, e.g. interpreter_args = ["$(foo)"]
2. location expansion, eg. interpreter_args = ["$(location :foo)"]
3. Runtime environment variable expansion, e.g. interpreter_args = ["%RUNFILES_DIR%"]

Should there be a way to unset an arg? The particular case I have in mind is: we want to switch to using -P for setting PYTHONSAFEPATH. Unfortunately, Python doesn't have any way to unset boolean interpreter args.

However, sometimes people want to disable this. A special value to indicate removal of an interpreter arg is somewhat appealing over a dedicated attribute. e.g. interpreter_args=["--UNSET=-P"] or interpreter_args=["-P=REMOVE"] and then the bootstrap removes -P from the interpreter args.

Should there be flag to add args? This just sounds generally handy, but I'm not sure what the use case would be.

Should there be a target-accepting attribute? Targets can be handy if more complex logic is desired. It can be easier than trying to express non-trivial select conditions.

Actually, this might be solved by supporting make vars expansion. Users are able to make arbitrary variables available by setting toolchains on the target and then having it return the TemplateVariablesInfo provider with the values they want.