Open Tenchi2xh opened 4 years ago
Hi @Tenchi2xh,
Yeah, the current implementation works properly only with decorators because Click declares it in its API for the most part. There is a piece of shit magic under the hood. This is not good. I will think about it, how we can do more elegant, simple and clear implementation.
Hi @espdev, @Tenchi2xh
I wrote an app framework using click, switched from argparse. I was able to avoid the usage of decorators from the framework users' point of view. Of course internally I had no choice but call the decorator methods. And to avoid unnecessary cognitive load I exposed the click.option(...) etc. parameters as are.
As a result I don't have to be careful with the order of the options as long as it's in order within the group but not absolutely. Futhermore I was able to introduce another useful feature, embedding groups within each other.
The base class for my commands is simple, it supports subcommand hierarchy with https://github.com/LA-Toth/dewi_core/blob/9ebb2a7f6c4168b6880523e0574994edca87da7d/dewi_core/command.py - and the options / argments wrapper: https://github.com/LA-Toth/dewi_core/blob/9ebb2a7f6c4168b6880523e0574994edca87da7d/dewi_core/optioncontext.py#L266
Hi!
In my current project, I have my own subclass of
click.Command
where I pre-initialise a bunch of options inself.params
.This list takes param objects and I was wondering if it's possible to instantiate an option group in this fashion without using the decorators? Have been peeking at the source here but wasn't able to find a way
Thanks!