BrianPugh
Cyclopts still enforces arguments count with custom converters
Parameter "x" requires n positional arguments. Only got 1
Isn't the point of custom converters to support types that can't be directly instantiated from the CLI arguments? It seems like it should be the custom converter's responsibility to complain if it needs more tokens.
Sort of! I'm assuming you are referencing custom converters? The history is a bit messy, but there used to be a Parameter.n_tokens attribute that would tell Cyclopts how many tokens should be parsed. This was removed as the types that Cyclopts supported grew and became more complex. However, we may be at a state where we can re-introduce it. Can you provide an example of how you would use this feature?
I'm assuming you are referencing custom converters?
ya. oops
Can you provide an example of how you would use this feature?
My current use case is a custom type that isn't actually instantiated from the CLI arguments. Rather, the CLI argument is used to select an existing instance.
More generally, I have cattrs setup for handling my type structuring throughout the program. I'm currently explicitly using it where Cyclopts can't convert something on its own, but might even want to set it on the default Parameter.
Running into the same issue myself. I have a type that I can create by loading from a file, so I create a custom converter that just expects a path that it can load. However cyclopts inspects the type and determines a bunch of sub-parameters it expects, even if I set accepts_keys=False, and then complains when I just pass in a path.
Using that branch I can solve my issue by passing n_tokens=1 (in addition to accepts_keys=False).
I do wonder if there is a better API where the converter specifies the inputs it needs? Ideally have a decorator for converter functions that parses the type hints for the function.
I had a similar initial thought, that at the very least it would be nice to group the n_tokens and converter function together. The obvious solution would be to make it a class, but that seems heavy handed and clunky. However, maybe I can make it work with @Parameter(n_tokens=1). I think that would be fairly elegant, I'll give that a try tomorrow!
@moloney I have updated this PR so that you can now decorate the function with @Parameter(n_tokens=1, accepts_keys=False). Additionally, it also works with classmethods now (via a string forward declaration). See the docs on that branch. Please give it a try!