The 3 current executables: mflux-generate, mflux-generate-controlnet, mflux-save and potentially other reasonable additions such as mflux-webui, etc will share common args and options.
I propose a refactoring to de-dupe the copy-pasted parser.add_argument calls across the N files.
easy 🔵💊
this is a no-op refactoring of the existing code
create a new package mflux.ui.cli and new module mflux.ui.cli.app where we keep the argparse.ArgumentParser objects but "organize" them into composable parsers that can be included in a specific facet of the CLI (i.e. generate vs. generate-controlnet vs save)
define parsers where args are grouped by whether they are destined for:
Flux1(...) # quantize, model paths, lora_{paths,scales}
from mflux.ui.cli.app import ModelArgParser, GenerateImageArgParser, ...
for the specific script e.g. mflux-generate, instantiate that script's own parser but include the common parser configs using the parents=[...] arg
this will allow for expansion of the CLI suite without continuing to dupe the similar args
inconvenient alternatives 🔴💊
refactor to something like Google's python-fire OR FastAPI's typer which will reflect (in the Java-like way) on your methods and auto generate CLIs. With this, you might just need a cli.py that provides wrappers to all the underlying functions to call.
refactor to click and accept the trade-off of additional deps in the core install, but gain the possibility of "free TUI" via trogon textual terminal ui. Both teams/projects are strong python community contributors so the risk is low/medium to follow their work.
These alternative implementations can easily be community project like mflux-fire-cli or mflux-tui but it would split the contributor energy a bit. (tbh, I'll start the click/trogon-based mflux-tui if no one gets to it before me)
I like these TUIs options over the GUI/webapp implementations because they couple to implementations in a way that's convenient to backend devs, all the while introducing much less code bloat to the core repo.
anthonywu
commented
4 days ago
The 3 current executables:
mflux-generate,mflux-generate-controlnet,mflux-saveand potentially other reasonable additions such asmflux-webui, etc will share common args and options.I propose a refactoring to de-dupe the copy-pasted
parser.add_argumentcalls across the N files.easy 🔵💊
this is a no-op refactoring of the existing code
mflux.ui.cliand new modulemflux.ui.cli.appwhere we keep theargparse.ArgumentParserobjects but "organize" them into composable parsers that can be included in a specific facet of the CLI (i.e. generate vs. generate-controlnet vs save)Flux1(...)# quantize, model paths, lora_{paths,scales}generate_image(...). # prompt, model, steps, guidance, seed, metadata etccontrolnet_image_path,controlnet_strength, etcfrom mflux.ui.cli.app import ModelArgParser, GenerateImageArgParser, ...mflux-generate, instantiate that script's own parser but include the common parser configs using theparents=[...]argthis will allow for expansion of the CLI suite without continuing to dupe the similar args
inconvenient alternatives 🔴💊
python-fireOR FastAPI'styperwhich will reflect (in the Java-like way) on your methods and auto generate CLIs. With this, you might just need acli.pythat provides wrappers to all the underlying functions to call.clickand accept the trade-off of additional deps in the core install, but gain the possibility of "free TUI" via trogon textual terminal ui. Both teams/projects are strong python community contributors so the risk is low/medium to follow their work.These alternative implementations can easily be community project like
mflux-fire-cliormflux-tuibut it would split the contributor energy a bit. (tbh, I'll start the click/trogon-basedmflux-tuiif no one gets to it before me)I like these TUIs options over the GUI/webapp implementations because they couple to implementations in a way that's convenient to backend devs, all the while introducing much less code bloat to the core repo.