Comments (9)
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.
from python-fire.
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!
from python-fire.
I agree that this should be cleaner and clearer.
Two pieces to this:
-
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 havedebug=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.) -
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 toError: 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]
?
from python-fire.
Update:
Just checked and argparse uses os.path.basename(sys.argv[0])
as their default. This makes me more comfortable to follow suit :).
from python-fire.
Created pull request.
Need help to write the test case for this change. I got confused between helputils_test.py
and fire_test.py
- Where exactly this test needs to add and how?
- Do I need to verify trace output by comparing with base file name?
from python-fire.
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
from python-fire.
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.
from python-fire.
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.
from python-fire.
Closing this ticket since the title-issue (the CLI name) is fixed.
We'll track the remaining improvements (improvements to verbose mode) in #77.
from python-fire.
Related Issues (20)
- [feature request] Exclude function (kw)args from synopsis, arguments and flags in help output
- guide sample code is entered incorrectly HOT 2
- Version flag alongside other commands HOT 3
- Remove test requirement on mock HOT 4
- Is it possible to pass arg via code and kwargs by cli (sys.argv) ? HOT 1
- cli for function created on the fly HOT 1
- ERROR: Could not consume arg: >> HOT 1
- AttributeError: 'module' object has no attribute 'PY34' HOT 1
- How to set the number of args at least one? HOT 1
- Python 2.7 no longer available in GitHub Actions by default HOT 1
- Unexpected printing (+paging) when using inspect HOT 3
- Cannot parse list of strings containing `is` HOT 5
- Gracias
- unable to install fire HOT 4
- Android 14 HOT 1
- What's the meaning of "available commands: as_interger_ratio | bit_count |..." HOT 2
- How to use the avialable command "S.xx", such as S.count HOT 2
- How to pass '2e9672320848' as a str value? HOT 1
- Optional type args are mistyped in help HOT 1
- Have all staff been laid off? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-fire.