NOAA-GFDL / fre-cli

Python-based command line interface for FRE (FMS Runtime Environment) to compile and run FMS-based models and post-process their output.
GNU Lesser General Public License v3.0
3 stars 9 forks source link

Refactor: Second level of lazy_loading? #98

Open bcc2761 opened 5 months ago

bcc2761 commented 5 months ago

Do we want another level of lazy_loading in fre-cli so that tool groups don't need relative imports? As of now, an example that can demonstrate this is fre make and fre pp. Basically, this will also organize existing scripts into more specific subdirectories so that the subcommand scripts aren't just scattered around within a tool group's directory. Subdirectories for template files and tests can also be created.

The current tree structure:

pp
├── checkoutScript.py
├── configure_script_xml.py
├── configure_script_yaml.py
├── edits-template.yaml
├── frepp.py
├── __init__.py
├── install.py
├── ppyaml_test
├── __pycache__
├── run.py
├── schema.json
├── status.py
├── validate.py
└── wrapperscript
make
├── createCheckout.py
├── createCompile.py
├── createDocker.py
├── createMakefile.py
├── fremake.py
├── gfdlfremake
├── __init__.py
├── __pycache__
├── README-fremake.md
└── runFremake.py

The envisioned tree structure:

pp
├── frepp.py
├── frepp_scripts
├── __init__.py
├── schemas
├── tests
└── README.md
make
├── fremake.py
├── fremake_scripts
├── __init__.py
├── tests
└── README.md

With a structure like this, the imports within the tool files (i.e. fremake.py) would have to include relative imports for each subcommand like: from .fremake_scripts.createCheckout import checkout_create

However, the tool group like make can itself become a lazy_group as well, with the capability to add its commands individually like in fre.py. However, this would take away the Click decorators in the file, and those would have to then be in the individual script files (this would mean that @click.pass_context won't need to be used, but scripts would need more rewriting).