Repository navigation
Enable developers to inject non-bolt arguments to listener function args #709
Description
Activity
- changed the title
[-]How to allow unknown kwargs[/-][+]How do I allow unknown kwargs in listener funcs?[/+]on Aug 24, 2022 Seems like a reasonable request to remove that part of the code. @seratch is the kwargs scrubbing code that @cooperbenson-qz linked to necessary to keep?
I'm happy to make a PR based on whatever determination you come to 😁
Reacted by Fil MajI agree that we can stop explicitly setting None to unknown args there, but I still would like to maintain the default behavior to print the warning logs. The log intends to make the dev experience more friendly by informing misspellings/typos of argument names.
Perhaps, adding a new option to disable the check to
Appinitialization may be a good solution for this use case.I like the idea of needing to specify an option to disable the "not a valid argument" warning message in situations where the framework is being used in an "expert" manner.
(I don't know if there are other similar log messages in the code where it might be nice to suppress them in less-typical use cases. If there are, naming the option something "generic" might be worthwhile so the option can be used in multiple places, instead of adding one for each warning whenever a situation like this comes up.)
Perhaps instead of using the logger to output the warning message, it might make sense to use warnings since that gives the user a lot of options for filtering and surpassing warnings.
- changed the title
[-]How do I allow unknown kwargs in listener funcs?[/-][+]Enable developers to inject non-bolt arguments to listener function args[/+]on Aug 25, 2022 @eddyg @cooperbenson-qz Thanks a lot for sharing your great insights. Indeed, using warnings for this purpose makes sense. Please feel free to add comments to #712 if you have any.
Sorry. After working on #712 a bit more, I've concluded my solution can't work at all and I cannot think of any elegant solutions for it. I myself am not going to use my time for it anymore.
If someone can enhance bolt-python to support the use cases mentioned here without breaking any existing code, we are happy to review the changes.
Until then, a workaround that I suggest is:
@inject def initialize_listeners( app: AsyncApp, # Inject your components here version: str = Provide[Container.config.VERSION], ): @app.command('/ping') async def handle_ping(ack, respond): await ack() await respond({ "blocks": [ SectionBlock(text=MarkdownTextObject(text='Pong!')), DividerBlock(), ContextBlock(elements=[ MarkdownTextObject(text=f'*Host:* {platform.node()}'), MarkdownTextObject(text=f'*Version:* {version}') ]) ] }) app = AsyncApp() initialize_listeners(app) if __name__ == "__main__": app.start()
Reacted by jj.lee
I'm using dependency_injector to provide automatic dependency injection for my application, and I'm encountering an issue with Bolt overriding injected parameters with
Nonesince it doesn't recognize them.Reproducible in:
The
slack_boltversionPython runtime version
OS info
Steps to reproduce:
(Share the commands to run, source code, and project settings (e.g., setup.py))
Expected result:
Bolt doesn't touch the
versionkwarg, but still injects theackandrespondkwargs.Actual result:
versionends up being set toNoneand Bolt logs the following warning:version is not a valid argument.This is caused by this line.
Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.