Closed skrobinson closed 1 year ago
@JacobDomagala
I've pushed a rough draft of an entrypoint
translation from Bash to Python. Is this a direction you are interested in?
Hey, sorry for late reply, been kinda busy lately.
Are there any advantages of using Python instead of Bash for entrypoint?
Hey, sorry for late reply, been kinda busy lately.
No worries.
Are there any advantages of using Python instead of Bash for entrypoint?
The advantage I see is reducing the complexity of repeatedly crossing the shell boundary. The current flow is bash > python > bash > python.
Reducing the quantity of execs avoids some stdin/stdout format issues between Bash and Python, e.g. commit 126be5f8. Also, does the current API via the shell correctly handle filenames containing spaces?
A recurring pattern in the existing code is to save stdout to a temporary file to be read later (see commit cd07e30a). Python's subprocess.run
can save command output to a variable for later use in the same script.
I left the subprocess calls to the two existing Python scripts, but the code in get_files_to_check.py
and run_static_analysis.py
could be moved into entrypoint.py
.
Optionally, git commands could be assumed into entrypoint.py
with pygit2
.
Ok, I like the idea of dealing only with Python environment. :+1:
Also, does the current API via the shell correctly handle filenames containing spaces?
That's a good question. I've never used names with spaces in my projects (that use this workflow).
I have not found the time to work more on this PR and likely won't have time before the end of the year. I'll close this PR but leave the branch in my tree if someone else wants to pick it up.
This is a translation to Python with minimal semantic changes.
Signed-off-by: Sean Robinson sean.robinson@scottsdalecc.edu