Exec-ing ninja when profitable?

[nextsilicon-itay-bookstein]

As it currently stands, the _program function in src/ninja/__init__.py uses subprocess.call.
When used via the ninja main, it merely waits for the exit-code and then propagates it as its own.
This is visible in that when this wrapper is Ctrl-C-ed, we see the interruption traceback in the Python interpreter.
In addition, a long-running Python process is parked without much remaining purpose.
I was wondering whether it would be a good idea to exec ninja instead of wrap it, when the platform supports it.
What do you think?

[henryiii]

Maybe it would be better (cross-platform) to handle these sorts of signals and just exit with the right error code instead of exposing the Python traceback? (Well, at least that would work on Unix...)

[mayeut]

Another option would be for the ninja executable to be directly deployed as a distribution script.
This should work as long as the ninja executable doesn't require to graft dependencies (i.e. as long as it's self contained).

This wouldn't change the fact that when calling through the ninja module, the remark would still hold. But, at least, when using the installed script in the path, there wouldn't be any python overhead at all.

[henryiii]

And you’d need to duplicate the executable, I think, since the module can’t reliably locate the scripts install location.

[mayeut]

If we can rely on importlib.metadata (or importlib_metadata), the module can locate the script (that would mean no more support for python <2.7 & python < 3.5).