Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.20%. Comparing base (b9c1390) to head (ee4e2db).
⚠️ Report is 534 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1943      +/-   ##
==========================================
+ Coverage   92.18%   92.20%   +0.01%     
==========================================
  Files         234      234              
  Lines       12213    12241      +28     
==========================================
+ Hits        11259    11287      +28     
  Misses        954      954              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Bumping this to the next milestone, since the required work in ESMValTool has not been done yet.

I looked into adding the fix for _path2facets(...) from #2066 to deal with cordex paths. I like the approach in this PR, it's very clear, and I believe it should be enough to add the following lines:

        elif sep == '-':
            if key not in facets:
                break
            else:
                value = facets[key]

to the loop over keys and separators before this line:
https://github.com/ESMValGroup/ESMValCore/pull/1943/files#diff-31cc786b90ae22835f79bf0f3dc2d5cea640d84ea42aeca926981450551a27ddR551

That way a facet followed by a hyphen separator must have already been extracted, which should take care of the cordex paths. If the facet is not already extracted, the extraction will simply stop. Of course, with this code there will be a limit to which facets can be extracted from a cordex filename alone, would that be an acceptable limitation?

Bumping this to the next milestone, since the required work in ESMValTool has not been done yet.

Dropping this for v2.10 for the same reason.

@bouweandela would you mind if I solved the merge conflicts here and make this PR ready for review? I would love to have this feature in v2.13.0.

Yes, that would be great @schlunma!

Turns out that including the changes from #2066 into this and making it fully backwards-compatible is not straightforward.

Thus, I decided to pursue a new regex-based approach in #2725. The basic idea there is to convert the templates to a regex pattern and then let the regex engine do the magic.