Open dbieber opened 7 years ago
Possible entry points for configs:
example -- --verbose
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.
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.
https://github.com/google/python-fire/issues/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.
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
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')
.
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?)
Adding to the list the ability to configure the order functions are displayed in the help screens https://github.com/google/python-fire/issues/298 PR: https://github.com/google/python-fire/pull/310
Hi, I would like to vote for the feature Allow passing arguments via stdin
I think there are actually two different features:
-
as an alias to read from the /dev/stdin 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'
I'm starting a list of things people might want to configure in their Fire CLIs
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.