Open jantari opened 3 years ago
@jantari this is an interesting request. We had originally called the parameter --query
or -q
, but today it is essentially a string we use as a filter. The current implementation uses a SQLLite database which doesn't contain all the metadata, so it's not likely to be performant with our current implementation. We would also need to look and see how this would work against a REST API. We've started discussions/design to improve the search APIs. I'll make sure the team is aware of this request to see what might be possible.
Description of the new feature/enhancement
winget can currently query packages by:
which is nice, but there will never be enough parameters and "expressiveness" within them to be able to really drill down into all package attributes and get precisely what one wants. The winget manifests are JSON or JSON-compatible YAML, so let us query the entire schema through JMESPath expressions/filters with a single parameter.
Proposed technical implementation details (optional)
JMESPath is a standard and there are many libraries available. The Azure CLI already implements it for querying azure resources, here's a MSFT article about that.
JMESPath allows to effortlessly query nested attributes, specify ranges, compare numbers, check for presence of an attribute, combine or restructure data etc. etc.. It's the one-stop solution for all package querying needs now and in the future as it evolves with the schema. For users wanting to use only basic search functionality the existing parameters will be preserved as-is.
I propose the subcommand
winget filter
as that would tie in nicely with #1407 because-Filter
is a common parameter name for PowerShell for specifying resource-specific and resource-provider-impemented advanced filters and queries like would be the case here.