🐛 Fix arg parameter of autocompletion#1134
Conversation
arg parameter of autocompletion
|
Related comment with links to the relevant code places: #1006 (comment) |
svlandeg
left a comment
There was a problem hiding this comment.
Thanks again for the contribution @bckohan, and for your patience while we're moving these different PRs to the review process! 🙏
I agree that this behaviour is not what is expected/documented, and the change in unit tests reflects the correct behaviour.
While I'm approving this PR, I will request an additional review from Tiangolo to get his feedback on the change, as he might have more information on why this was implemented originally the way it was.
…08.py Co-authored-by: Sofie Van Landeghem <[email protected]>
…08_an.py Co-authored-by: Sofie Van Landeghem <[email protected]>
tiangolo
left a comment
There was a problem hiding this comment.
It seems that the current logic is indeed incorrect.
Nevertheless, trying out this PR seems to still be incorrect. Using it from the Docker Compose script I get this completion from Zsh:
It prints the list ['demo.py', 'run', '--name'] and then shows the options.
Before this PR, it would print an empty list [] and then show the same options.
|
This pull request has a merge conflict that needs to be resolved. |
Separated from #1006
Bug documented in #1133
One note on the implementation. Because the CLI options during an autocompletion run are passed through shell-specific mechanisms (usually environment variables) and are not available in sys.args we have to resort to adding this information to the context in the completer classes. Click provides a mechanism to do this using ctx_args and the "obj" parameter. Obj is seldom used, but it can be anything per the click docs. Right now I do not believe the click code path sets it to anything. This PR sets it to a dictionary if it isn't already and if it is dictionary it sets the args key to be the arguments passed by the shell specific mechanism. This would be brittle to obj being set somewhere upstream to anything but a dictionary. I think this is unlikely to happen, but if it does it will not brick the code, it'll just revert to the current behavior (empty list) and the CI will fail.