ClusterRunner usage prints main.py instead of executable name

[shriganeshs-zz]

ClusterRunner should print name of executable i.e. clusterrunner when outputting help/usage.
Here is the current output.

[root@pod4101-overmind01-jenkins-slave-packer-builder ClusterRunner]# clusterrunner -h
usage: main.py [-h] [-V] {master,slave,stop,deploy,build,shutdown} ...

[josephharrington]

https://docs.python.org/3/library/argparse.html#prog

[josephharrington]

We can fix this in argparse but I feel like the default behavior of argparse is very sensible -- it tries to print a message that matches how the application was invoked.

@gcurtis I'm wondering if Flute should handle this as a more general case. It seems like Flute could create a wrapper that calls main.py in such a way that sys.argv[0] would be set correctly. (For example, maybe Flute could create a symlink which matches the entry point named as defined in the .flute file, then creates a wrapper that executes via the symlink.)

(cr) 🍕 🍕 🍕  ☰  python main.py -h
usage: main.py [-h] [-V] {master,slave,stop,deploy,build,shutdown} ...

(cr) 🍕 🍕 🍕  ☰  ln -s main.py clusterrunner
(cr) 🍕 🍕 🍕  ☰  python clusterrunner -h
usage: clusterrunner [-h] [-V] {master,slave,stop,deploy,build,shutdown} ...

[josephharrington]

Just to clarify, I believe this is specific to Flute-built RPMs. When building with cx_Freeze we did not have this problem.

[gcurtis]

I feel like adding a symlink would be kind of hacky. Why do we not just want to change the prog parameter or change sys.argv[0]? I've noticed that this is what some Python scripts do to get the correct executable name:

# /usr/local/bin/pip

sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])

[josephharrington]

Why do we not just want to change the prog parameter or change sys.argv[0]?

It's just the reason I stated above -- the default behavior for argparse makes sense. If I'm running it via ./main.py then it's a bit strange that it's telling me to execute clusterrunner when that may not exist in my path.

To be clear I'm totally fine with fixing in argparse, I just wanted to make the point that this is technically Flute's responsibility since:

• Flute is the one accepting the mapping from <executable name> to <python script>.
• There's nothing enforcing that whatever we'd set the prog name in argparse would match what we put in the .flute config file.
• We have an example usage of Flute internally where we use Flute to create multiple entry points to the same main.py (to enable backwards compatibility). In that case it's currently not possible to have both entry points print the correct invocation help.

[gcurtis]

Actually, it looks like we can do exec -a 'clusterrunner' .... That's probably the correct fix.

[josephharrington]

Oh good one. Way better than symlink. 👍