Bug in ccpp_track_variables.py

[grantfirl]

Description

The ccpp_track_variables.py script has not been updated since the ccpp-physics repository changed its organization, so the code that finds all metadata recursively isn't working as intended. The following change should fix the issue:

diff --git a/scripts/ccpp_track_variables.py b/scripts/ccpp_track_variables.py
index 64dfc51..1f77b49 100755
--- a/scripts/ccpp_track_variables.py
+++ b/scripts/ccpp_track_variables.py
@@ -69,7 +69,7 @@ def create_metadata_filename_dict(metapath): with that scheme"""

metadata_dict = {}
- scheme_filenames = glob.glob(os.path.join(metapath, "*.meta"), recursive=True)
+ scheme_filenames = glob.glob(os.path.join(metapath, "**/*.meta"), recursive=True)

Steps to Reproduce

Try to run ccpp_track_variables.py on a recent commit of UWM or CCPP-SCM.

Additional Context

Output

[mkavulich]

@grantfirl The original fix for this was #581...at the time I did not include the ** for recursive globbing by default because I thought it may be useful for users who are only interested in the routines in a particular directory. Basically I defaulted to maximum flexibility (since you can still run recursively with the argument -m './physics/physics/**/', as is directed in the tech doc). But maybe that flexibility is unneeded, and results in an additional burden/confusion for users who just want to track everything.

[grantfirl]

@grantfirl The original fix for this was #581...at the time I did not include the ** for recursive globbing by default because I thought it may be useful for users who are only interested in the routines in a particular directory. Basically I defaulted to maximum flexibility (since you can still run recursively with the argument -m './physics/physics/**/', as is directed in the tech doc). But maybe that flexibility is unneeded, and results in an additional burden/confusion for users who just want to track everything.

@mkavulich OK, so I guess there really isn't an issue and I should have read the docs!

[grantfirl]

@mkavulich I guess I'm not really understanding the use case for confining the search to a particular directory. I.e. I would think that that everybody would want to track a variable throughout an entire SDF, not just the pieces of an SDF from a specific directory.