My goal is to reduce all pod/version queries into a single query language that can be used by both humans and tools. I believe this design maximizes flexibility and keeps a simple single code path for all query operations.

The general format will be:

nameFilter [versionFilter] [metaFilter]

If you want to perform multiple queries at once you can separate them with a comma.

Name Filters

Name filter would be simple string with optional "*" wildcard:

sidewalk     // match the pod name "sidewalk"
sidewalk*    // match any pod name which starts with sidewalk
a*           // match any pod starting with "a"
*            // match any pod

Version Filters

The version filter is optional. If omitted, we assume we are matching current version. The version syntax would reuse sys::Depend syntax as much as possible:

foo 1.2       // any version of foo 1.2 with any build or patch number
foo 1.2.64    // any version of foo 1.2.64 with any patch number
foo 1.2+      // any version of foo 1.2 or greater
foo 1.2-1.4   // any version between 1.2 and 1.4 inclusive
foo 1.2,1.4   // any version of 1.2 or 1.4

So in simple cases the query language is a clean superset of the Depend syntax. This means its easy to find a dependency. If we assume that the -n option limits the number of matching results, we can query the best match for a dependency like this:

fanr query -n 1 "foo 1.0"

We can also build up a compact filter to query which new patches available for my current local installation:

fanr q -n 1 "a 1.0.34, b 1.0.34, c 1.2.66, d 1.2.67"

This would return latest patch versions of my specific versions of a, b, c, and d.

Meta Filters

I think where we really take things to the next level is to allow queries on arbitrary metadata props which are specified by the pod. I proposed a couple new ones in #1520. To keep the grammar sane and flexible for future enhancements, I am going to limit meta filters to props with a dot in the name (which is convention anyways).

Here are some examples of what I am thinking:

* org.name == SkyFoundry   // any pod where org.ame == "SkyFoundry"
* org.name ~= SkyFoundry   // orgName.lower.contains("SkyFoundry".lower)
* pod.docSrc               // pod.docSrc is present and not "false"
* build.ts >= 2011-05-01   // build time on or after May 1st

In the case of the comparison operators < <= => >, the right hand is a scalar that implies how to parse the prop value:

DateTime <=> Date
Version  <=> Version
Int      <=> Int

Other Considerations

The comma provides a basic "or" filter. I thought comma makes sense for a set of common use cases to compare current environment versions against repo versions. But we could really do a whole and/or/nested paren groups too. But I can't really think of any use cases, so thinking we should avoid that complexity for right.