Summary of the new feature / enhancement
As a user, I want to quickly filter for available functions by their metadata,
so that I can search for relevant functions when I don't know their name
without having to retrieve all functions and filter with a pipeline.
In the current release of DSC, the only filtering option available for the dsc function list command is the argument for function name, which accepts wildcards (*).
It would be useful to also be able to filter on category and description.
Aside: filtering lambdas
I can also see value in filtering on other properties, but they're more difficult to express neatly at the CLI. One generic option, which would probably be very useful long-term but requires too much effort to develop and maintain without more user feedback indicating it's a high priority, is to define a filtering syntax that the user can provide for DSC to enact.
I don't think we should do this work as part of resolving this issue, but I wanted to bring it up for future consideration (and can extract into a separate issue or discussion if we decide to keep this context without committing to it).
The lowest effort (and likely most robust from a maintainability perspective) option is to enable them to pass a JQLang filter, like:
$filter = 'select((.minArgs > 1) and (.category | contains(["Object"])))'
dsc function list try* --jq-filter $filter --output-format yaml
Which would return
category:
- Array
- Object
name: tryGet
description: Attempts to retrieve a value from an array (by index) or object (by key). Null is returned if the key or index does not exist.
minArgs: 2
maxArgs: 2
acceptedArgOrderedTypes:
- - Array
- Object
- - Number
- String
remainingArgAcceptedTypes: null
returnTypes:
- Array
- Boolean
- "Null"
- Number
- Object
- String
This is potentially doable with the jaq-all crate, which provides a high-level API for filtering data on JQ expressions.
Proposed technical implementation details (optional)
The simplest implementation, I think, would be to add two new options to the command:
--category, accepting a literal category. Users can specify multiple times to create and AND filter, so dsc filter list --category Array --category Object would only return functions with both the Array and Object categories.
--description, accepting a string with wildcards that matches on the text of that field.
Later, we could add support for wildcard categories, though the technically correct way to do that would require a new type that raises an error when the given category filter can't actually match a defined category, like --category z*z.
Summary of the new feature / enhancement
In the current release of DSC, the only filtering option available for the
dsc function listcommand is the argument for function name, which accepts wildcards (*).It would be useful to also be able to filter on category and description.
Aside: filtering lambdas
I can also see value in filtering on other properties, but they're more difficult to express neatly at the CLI. One generic option, which would probably be very useful long-term but requires too much effort to develop and maintain without more user feedback indicating it's a high priority, is to define a filtering syntax that the user can provide for DSC to enact.
I don't think we should do this work as part of resolving this issue, but I wanted to bring it up for future consideration (and can extract into a separate issue or discussion if we decide to keep this context without committing to it).
The lowest effort (and likely most robust from a maintainability perspective) option is to enable them to pass a JQLang filter, like:
Which would return
This is potentially doable with the
jaq-allcrate, which provides a high-level API for filtering data on JQ expressions.Proposed technical implementation details (optional)
The simplest implementation, I think, would be to add two new options to the command:
--category, accepting a literal category. Users can specify multiple times to create andANDfilter, sodsc filter list --category Array --category Objectwould only return functions with both theArrayandObjectcategories.--description, accepting a string with wildcards that matches on the text of that field.Later, we could add support for wildcard categories, though the technically correct way to do that would require a new type that raises an error when the given category filter can't actually match a defined category, like
--category z*z.