Brilliant workflow!

Today I learned about Fire AND Gooey

Sometimes I get bogged down in writing proper argparse when it really is not needed.

Are there any edge cases where Fire does not work too well, like some strange parameters (for example tuple as dictionary key)?

If you like the look of fire for the ease of creating a cli but wish it automatically did validation based on type annotations, you might like Typer[0]. The pathlib parameters are especially handy, I find.

[0] https://github.com/tiangolo/typer

You had me at pathlib! I wish people used it more...

For anyone who doesn’t know what pathlib is: https://docs.python.org/3/library/pathlib.html

I love fastapi I wish I knew about this before!

I also recommend checking out Clicky. It is similar to Fire, but has been out there for very long time and has some more power features and documentation.

Same! TIL Fire & Gooey is a power move.

Same! Thanks.

I've been using Gooey quite a lot lately and I'm really tired of setting up Argparse every time. Your recommendation of Fire came at exactly the right time! Thanks

an interesting related tool is https://github.com/fredrik-corneliusson/click-web which builds on the click library to create web front ends automatically.

Oh damn, that's fantastic! I wanted to write a small server that did something between this and Fire above (i.e. allowed you to drop a Python script into a directory and would create a UI for its functions). It's a great way to make small, random functions I've written accessible to people with zero work.

Just found out about this, looks cool! Unfortunately file handling is a bit wonky, I suspect some of that is just the web platform (e.g. can't select directories), while some of it is probably due to a lack of bandwidth from what looks to mostly be a solo developer.

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?

Actually, 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()

Seems 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?

Thanks for the info. Where does your code/Gooey/Fire live? If I wanted to take a Python script to use, where do I put it with this setup?

In our setup, we have a class that does the heavy lifting. The file where that class lives ends with :

    if __name__ == '__main__':
        fire.Fire(JobManager)

which turns it into an instant CLI.

Then we have a separate gui.py file, which contains the Gooey code. This includes the class mentioned above, and builds a minimalistic GUI around it. This does need some argparse-based code, but in the GUI we only expose a small subset of the full power, so we only need a little bit of argparse-code.

P.S. I'm not certain this is the best way to approach things, but it's the way we use it, and we're happy with it so far.

Does anything like Fire exist for JS?

Fire is great