Project scope

[wpbonelli]

What is the proper scope of modflow-devtools?

This project began as a home for shared test fixtures/patterns and miscellaneous utilities that didn't seem to fit naturally anywhere else.

Forward-looking modflow developments already live in git / on GitHub. As the legacy modflow world moves to the same approach, if only for easier management of executables if not continuing support/development, devtools could become a multitool for it all.

Ideally devtools would not need to know intimate details of any particular program, just define contracts that other repositories can satisfy to "opt in" to the ecosystem. Each program repository can be responsible for itself, and choose whether/when to fulfill the contract to become visible to / play nice with everything else.

This cuts across multiple features either in ideation, prototyping, or early development at the moment:

• Models API #134
• Programs API #263
• DFNs API #262

[wpbonelli]

Discussed with @jdhughes-dev and tentatively agreed to go ahead with this. Devtools could then have two optional dependency groups:

• test, as already exists
• ????, with all the ecosystem management tools mentioned here (programs, models, specifications), merging existing dfn and models groups. not sure what to call this, maybe ecosystem?