OpenCDSS / cdss-app-statecu-fortran

Colorado's Decision Support Systems (CDSS) StateCU consumptive use model code, documentation, tests
GNU General Public License v3.0
1 stars 1 forks source link

Add "require" to response file #27

Open smalers opened 3 years ago

smalers commented 3 years ago

There may be a need to ensure that a StateCU dataset is only run with software that is the appropriate version. This could prevent confusion for users.

I have been adding #@require comments to TSTool and StateDMI test command files and also used for the recent well processing command files for ArkDSS StateDMI. The basic idea is to use a comment like the following. Note that this syntax is used in TSTool and is one generation ahead of StateDMI. I'm updating StateDMI similarly. The end of the check is implemented in the specific software and can be any check.

#@require app StateDMI version >= 1.2.3
#@require datastore HydroBase version >= YYYYMMDD

This allows the software (if it understands these comments) to do the check and exit out if the requirement is not met.

The same approach could be taken for StateCU executable to check that the executable being used is consistent with a version that was used to develop the dataset. There may also be cases where a dataset is frozen/archived (such as for court case, etc.) and an older version of the executable needs to be ensured. At the moment this won't be possible unless the older code is recompiled to check the requirement.

If a wrapper program like statecu.cmd is used to actually run the software, then the wrapper could also be smart enough to try to locate the correct version of the software. The concept of a wrapper or launcher program is similar to what Python does on Windows:

https://stackoverflow.com/questions/50896496/what-is-the-difference-between-py-and-python-in-the-terminal

Finally, this concept could be extended to include other properties. For example, TSTool and StateDMI use @enabled False and @expectedStatus Failure in testing.