Description of the new feature/enhancement
winget can currently query packages by:
- id
- name
- moniker
- tag
- command
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.
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 filteras that would tie in nicely with #1407 because-Filteris a common parameter name for PowerShell for specifying resource-specific and resource-provider-impemented advanced filters and queries like would be the case here.