Better Windows CLI name

[g-berthiaume]

Windows user here.
Could that be possible to add a configuration to modify the default CLI name ? Right now, depending on the user way to interact with the script, it can become noisy.

Note:
The following figures all use a script base on the calculator example.
Python 2.7.13
Windows 7 OS

e.g. When launching a script directly with a .py, it can become noisy:

e.g. A worse case senario with CLI_FIRE_A_BIG_NAME_FOR_SCRIPT.py in a directory far far away.

e.g. In the best case scenario, it can be attenuated if you have setup Python.exe in your environment variable.

Questions:

1. Is it possible to do ?
2. I didn't find any doc about configuring the "help when error" display (except the docstring) is this in development ?

Thanks.

[dbieber]

This looks like it can be improved. Perhaps only the basename of sys.argv[0] should be shown in the Usage section. What do you think?

To answer your question 1: yes, there is an undocumented argument to the Fire() function that you can use: fire.Fire(object, name="cliname"). Note that future versions of Fire may remove this argument which is why it isn't documented.

To answer your question 2, no, the only way to set the --help is to update your docstrings (of course the help also changes when the function signature changes, or the object's members change, etc). There is also a plan to improve some of the usage strings further.

[g-berthiaume]

Using sys.argv[0] seams like a great solution to me.

Concerning the --help, my main concern is about the "verbose" nature of the fire auto-generated help. Note: My application targeted audience is often beginners. For this reason, i may have a bias towards a more "none-verbose/self-documented CLI" than the average developer.

For example, this small Click CLI. In this example, the auto-generated help wants to communicate to the user that there's a missing argument. (here the "name" arg)

Now this small fire CLI. In this example, the auto-generated help also wants to communicate to the user that there's a missing argument. (here the "y" arg)

Fire auto-generated help is more detailed (perfect to debug), but for an average user, the type line, the string from line, the file line and line line seams too much, in my option. Of course this kind of things are subjective. What are your thought about this?

Thanks again for your work!

[dbieber]

I agree that this should be cleaner and clearer.

Two pieces to this:

1. There is definitely a use case for applications that don't show type, string form, file, + line, as those are developer features. Maybe this should be set by a debug argument when you call Fire. e.g. fire.Fire(debug=False). By default, I think we'd have debug=True. Open to other ideas. This would be the first (documented) config we add to Fire, so I'm hesitant, but I think it could be worthwhile. (We would not do this without first considering the change in the context of other configs we may want to add in the future.)

2. Even when we do show all that information, there's definitely still room to clean up the output.
   As a first step, we can remove the excess parentheses and quotes and clean up the error strings so it's closer to Error: Missing argument "y".
   It may make sense to move the error to the final line, possibly by moving the Fire trace to after the Usage section, or by putting the error in it's own section at the end.

---

Using sys.argv[0] seams like a great solution to me.

We do use sys.argv[0] currently. I guess on Windows sometimes sys.argv[0] has the whole path?
What do you think about using os.path.basename(sys.argv[0]) instead of just sys.argv[0]?

[dbieber]

Update:
Just checked and argparse uses os.path.basename(sys.argv[0]) as their default. This makes me more comfortable to follow suit :).

[saurabhkpatel]

@dbieber

Created pull request.
Need help to write the test case for this change. I got confused between helputils_test.py and fire_test.py

1. Where exactly this test needs to add and how?
2. Do I need to verify trace output by comparing with base file name?

[Shaddy]

I'm confused with the verbose meaning, for me, w/o any knowledge about the internals overlaps a bit the "debug" concept. How about with different levels? We could reuse verbose parameter. Something like this.

# helputils.py:186
 debug_fields = [
      'type_name',
      'string_form',
      'file',
      'line',

      'docstring',
      'init_docstring',
      'class_docstring',
      'call_docstring',
      'length',

      'usage',
  ]

  default_fields = [
    'docstring',
    'init_docstring',
    'class_docstring',
    'call_docstring',
    'length',
    'usage'
  ]

  # level.debug, level.verbose
  fields = debug_fields if verbose.debug else default_fields

[dbieber]

Currently verbose only controls whether private methods/members are shown. That is, those members that start with an underscore. And currently debug does not exist.

Moving forward we'll want to clean up the default output of CLIs. One way to do this would be to introduce the debug flag which would be set by the developer. Another way to do this would be to modify the meaning of verbose, which is used by the CLI user.

Whichever approach we go with, you have the right idea about what will have to change ^^ in helputils.

[Shaddy]

Thanks for the clarification :). It sounds like verbose fits more with what debug meaning should be, and the actual verbose should be renamed to something like access or scope so it'll have well separated both different concepts.

If it should be split into two parameters, or create an intermediate object it's just a design decision.

[dbieber]

Closing this ticket since the title-issue (the CLI name) is fixed.
We'll track the remaining improvements (improvements to verbose mode) in #77.