4 ms·
I’m not familiar with Fire, but I assume it uses argparse under the hood? Do you put the Gooey annotation on the function that calls fire.fire?
by legobmw99 5y ago
I’m not familiar with Fire, but I assume it uses argparse under the hood? Do you put the Gooey annotation on the function that calls fire.fire?
- frederikvs 5y agoActually, I misspoke slightly when I said it turns the GUI into a CLI. Rather, it turns the same underlying class into a GUI. So we have one file which contains the class with all the functions we want to expose (in our case, the class is named JobManager). At the end, it goes if __name__ == '__main__': fire.Fire(JobManager) which takes care of all the CLI access we could want. Then we have a second file for the GUI, which has a main-function that does some argparse stuff. The GUI interface is simplified from the CLI interface, so it's not that much work to write the argparse code for that. Simplified, it looks a little like this : @Gooey(default_size=(1000, 600)) def main(): parser = GooeyParser(description="jobGUI") # argparser code args = parser.parse_args() JobManager(args.name, args.whatever) if __name__ == '__main__': main()
- jmholla 5y agoSeems like you have update your API in two locations when changes happen, once in the `JobManager` definition and another time in the parser. How do you avoid issues with inconsistency?