-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support command composition #7
Comments
Possible design:
When using a single command as above, arguments from
|
Hi, I'm the guy you quoted on reddit for this enhancement suggestion. I just now got around to trying to implement something like this using defopt, but I've run into a few problems. Here's my approach: I wanted a class that would manage layers of config, provide logging, and provide a CLI (I might need to work on Single Responsibility Principal, but we'll ignore that for now):
Here's how I'm going about it so far:
OK, so hopefully most of that makes at least a little sense. The magic/troublesome bits are the
In order to attempt casting kwargs to reasonable types, I also use a helper function:
Finally, I noticed that keyword-only arguments that don't have a default value are treated as positional arguments. I think that's a bug. Anyway, I hope that all makes some sense, clears up my use case, and maybe gives you some ideas about a decent way to handle kwargs. This is a cool project. It's a joy to use. Thanks for your awesome tool! |
A similar approach to your proposed design could be:
|
Thanks for the detailed comments! I've just skimmed them for the moment but I'll come back and have a proper look in the next few days. I've opened #13 for keyword-only arguments without defaults. I had no idea you could even do that, so it's a pure accident that it works the way it does currently. |
The reason I initially didn't want to automatically pick short flags is that adding a parameter to any of the called functions could then unintentionally steal a short flag from another argument. I like the idea of |
I've thought about this a lot more. Most of the little things I suggested like I've also realized that It could look like so:
That's all I've got so far. I'm not 100% how parents works with an I can try to implement this in a feature branch and so that it's a little more fully baked. |
Do you have some examples in mind for how this would be used and what the resulting command line would look like? |
I think the main problem I have with zipping up the extra arguments into |
Having said that, I do like the idea of having a class to allow for more tweaking of the internals that you're after. Then it might be relatively simple to add If you do end up working on this in a branch, keep me updated. |
Sorry it took me so long to get back to you. My thought is that you don't have to make a decision about how specifically to handle *_kwargs now or really ever. It would be nice to have a way to add a *_kwargs handler to a parser. The interface for a **kwargs handler is pretty simple: take a list of strings and return a keyword arguments dictionary. Argument parser has a function to produce that list of strings: If there is a kwargs_handler and the function has kwargs argument, pass I will for sure keep you updated on any work I do on defopt. |
I'll work on a branch that implements some of the things i'm talking about so it's more clear |
Adding an unknown_args_handler as suggested in #7 (comment) seems reasonable, e.g. along the lines of
although this likely needs kwargs support (#3, or rather at least allow them to be ignored on the CLI side) to be really useful (so that the handler can e.g. add more kwargs). I'll leave the implementation to anyone who has a real use for this, though. |
I'm going to consider that this is effectively provided by defopt.bind_known. |
Specific feature request:
Source
This is within the realm of possibility but I'm looking for a clean design. Suggestions are welcome.
The text was updated successfully, but these errors were encountered: