Brainstorm potential Fire CLI configurations

[dbieber]

I'm starting a list of things people might want to configure in their Fire CLIs

• Set a function to always show --help, rather than trying to display the output. (Limit member exposition from an instance #47)
• Prevent CLI access to private members (Limit member exposition from an instance #47)
• Prevent CLI access to specific members (Limit member exposition from an instance #47)
• Configure how a particular type is serialized
• Set a parse function for a particular input argument (L32)
• Cache a particular input to a fn
• Cache a function's output
• Set a custom help string
• Make a member available by a different name.
• Make an argument available by a different name.
  • Enable single-letter options.
• Allow passing arguments via stdin (what would be the syntax?)
• Whether to use environment variables as arguments (Support for environment variables as default #94)
  • What prefix to strip from environment variables (Support for environment variables as default #94)
• Enabling post mortem debugging (add post-mortem pdb flag #71)
• Don't parse arguments to a function (pass them all as strings) (would enable Use fire without editing code directly #29)
• How verbose should Fire be? (improvements to --verbose mode #77)
• Freezing completion autogeneration after Improve Python Fire's tab completion #32 is implemented (Improve Python Fire's tab completion #32)

By no means do we plan on supporting all of these; just good to keep a list.

The primary reason for making this list is so that as we start adding support for these, we can do so in a way that's forward looking. We want any configs that we introduce to look and feel consistent with each other, and not to later need to be renamed or removed for consistency with other configs added at a later date.

[dbieber]

Possible entry points for configs:

• fire.Fire's **kwargs
  • fire.Fire(name='example')
• Flags
  • example -- --verbose
• Decorators
  • @fire.decorators.SetParseFn(str)

[mrshu]

Just came here to say that I would very much appreciate if this was possible:

Allow passing arguments via stdin (what would be the syntax?)

I would suggest going with single dash, as that seems to be customarily used in many *nix tools.

[grofte]

How about adding type hints to the functions/classes passed to fire?

So I could have

import fire

def use_gpu(gpu: bool = True):
    pass

fire.Fire(use_gpu)

and then python test.py --gpu=false would crash because false is interpreted as a string rather than a boolean.

[dbieber]

#220 requests the ability to exclude certain objects from Fire's help, e.g. imported modules, and local variables. This could be accomplished through fire.Fire(excludes=[fire, logging]) or fire.Fire(commands_only=True). (Same as #47, or the 3rd item on the list in the original post.)

[dbieber]

#231 suggests being able to disable the printed output for use cases where the developer wants to do something with the returned component from Fire.

[danlkv]

Hi, I would like to vote for the feature Allow passing arguments via stdin

The syntax could be yaml or json. Yaml is more flexible, for example it automatically parses date and has syntax for using custom data type. Json is faster.

The usecases could be chaining output of one to input of other, but using all power of unix with tools for cli json editing like jq, counting words, and dumping to file or db.

I suggest two ways of implementation

1. Wrap invocation
   I used same approach in my mongocat cli tool for mongodb. My solution was quite simple:

class MongoCat:
...
    def writeln(self, line):
        object = self.parser(line)
        self.put(object)

https://github.com/DaniloZZZ/mongocat/blob/master/mongocat/mongocat.py#L32

In the case of fire we can have our method of interest instead of self.put. There should also be possibility to specify users own parser, for example in call to fire: fire.Fire(func, use_stdin=True, parser='json').

2. Decorator
   Another nice syntax could be a decorator that wraps the function so it reads stdin. The usage would be like this:

from fire import parse_stdin

@parse_stdin(parser='json')
def my_foo(arg1, arg2='foo'):
    print(arg1, arg2)

(maybe I should add an issue for this feature?)

[dbieber]

Adding to the list the ability to configure the order functions are displayed in the help screens
#298 PR: #310

[nfultz]

Hi, I would like to vote for the feature Allow passing arguments via stdin

I think there are actually two different features:

1. use data from stdin as arguments, perhaps variadically or perhaps with multiple invocations. xargs does this well for me
2. Use stdin as an input filename - some programs that expect filenames as args can also accept - as an alias to read from the /dev/stdin

[geekscrapy]

Came here to ask about stdin.

My use case is: echo 'some data' | my_fire_script.py command -

Where command function is something like def command(*text):

but it could also be called like this:

$ my_fire_script.py command 'some text'