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
Add --config option to use different config file. #79
Conversation
Nice idea. But for me it doesn't work. Problem is, that the set_default_subparser function must be The only thing, I could imagine is to take the default action from the default config file, parse |
Sorry, that doesn't work. First, as you've already pointed out, command line options wouldn't work any longer for the default Second: Try to set phone or email as your default action and run khard without any action or command Please also see the commit a67f88a for further information. |
I have another idea how we could do this: We could do runs of parse_args() and construct some command line parsers intelligently to incorporate the default action in the second run. But I will wait for the other open PRs to make merge conflicts less likely. Especially I would like you to merge #94 before I revisit this. |
The argparse patch is also removed. The command line is parsed in two steps in order to make it possible to - use the config file given on the command line - display the help message before parsing the config file - set the debug option before parsing the config file - get the default command from the config file if none was given on the command line Currently there is one undesired side effect: If no subcommand is given on the command line no options for the subcommand can be given on the command line as well. Previously this was possible.
On the second parsing step the remainder of the first parsing step is parsed instead of reparsing the whole command line. This makes it possible to inject the default command from the config file with minimal effort if no subcommand was given on the command line. This fixes the regression mentioned in b2c8273: It is now again possible to specify arguments to the default command without specifying the default command itself (with the exception of all options that are valid to the main parser). This also makes it possible to specify general options (like --debug or --config) after the subcommand or its arguments. They will be processed by the first parsing run.
I implemented the two step parsing and changed the merge target to
If you merge this try to keep these commits as one of the commit messages mentiones a commit hash of another (or you have to change the commit message). |
Looks really good. Even the default action is processed well. Thanks for reorganizing. I only found one bug so far. If you run
the general help text is shown but if you run
it's also the general help and not the help text for the phone action. |
The remainder of the command line is explicitly collected in the first parsing step. This allows the parse_args() method to be used instead of parse_known_args(). The latter did skip any unknown args in order to process more elements of sys.argv. Thereby it did find the help options of subcommands. With the remainder argument in the first parser parse_args() can be forced to stop processing at the first unknown argument. This has the side effect that no global options can be given after the first non global argument. This is the case with either an explicit or implicit/default subcommand. So `khard some-search-terms -h` will give the help of the default subcommand.
I think I fixed it but there is a small (in my opinion acceptable) trade off: Some commits back we could specify global options after the subcommand. Now this can't work anymore b/c it was exactly that which "eat" the |
I can live with that. Works.
|
I already had tests for this in #96 and didn't notice :( |
Merged into develop branch. |
How do you merge these commits all the time to get new commits? (Git does not recognize that you merged them. Did you do Thanks anyway |
No description provided.