Found while writing an ordinary program with Pyfun 0.5.0.
pyfun run gives the program its own stdin (#35), but not its own argv:
anything after the file path is silently dropped, so a program that reads
sys.argv behaves differently under pyfun run than compiled.
# args.pyfun
extern import sys
extern getArgv: unit -> List string = sys.argv.copy
print (getArgv ())
$ pyfun compile args.pyfun -o out && python out/args.py hello 42
['out\\args.py', 'hello', '42']
$ pyfun run args.pyfun hello 42
['C:\\...\\pyfun_run_34292\\_pyfun_main.py']
$ pyfun run args.pyfun -- hello 42
['C:\\...\\pyfun_run_11416\\_pyfun_main.py']
No error, no warning — the arguments (with or without a -- separator) just
never arrive, and there is no other way to hand them over.
Why it happens
The CLI takes only the path: Some("run") => match args.get(1)
(src/main.rs:49) never looks past it. Both interpreter invocations pass the
staged script alone — Command::new(&interp).arg(dir.join(entry_py)).status()
in run (src/main.rs:241) and the same shape in run_project
(src/main.rs:427). Forwarding args[2..] (or everything after --) with
.args(...) in both places would make run and the compiled program agree.
Where it bit
Super Scrabble now takes an optional seed as its first argument, so a deal
can be replayed (python build/main.py 123456789). Under pyfun run the
seed cannot be supplied at all, and the README has to tell people the feature
needs the compiled form. #35's rationale — a program under run should
behave like the real program — seems to apply to argv exactly as it did to
stdin.
Found while writing an ordinary program with Pyfun 0.5.0.
pyfun rungives the program its own stdin (#35), but not its own argv:anything after the file path is silently dropped, so a program that reads
sys.argvbehaves differently underpyfun runthan compiled.No error, no warning — the arguments (with or without a
--separator) justnever arrive, and there is no other way to hand them over.
Why it happens
The CLI takes only the path:
Some("run") => match args.get(1)(
src/main.rs:49) never looks past it. Both interpreter invocations pass thestaged script alone —
Command::new(&interp).arg(dir.join(entry_py)).status()in
run(src/main.rs:241) and the same shape inrun_project(
src/main.rs:427). Forwardingargs[2..](or everything after--) with.args(...)in both places would makerunand the compiled program agree.Where it bit
Super Scrabble now takes an optional seed as its first argument, so a deal
can be replayed (
python build/main.py 123456789). Underpyfun runtheseed cannot be supplied at all, and the README has to tell people the feature
needs the compiled form. #35's rationale — a program under
runshouldbehave like the real program — seems to apply to argv exactly as it did to
stdin.