Is your feature request related to a problem? Please describe.
We have immutability requirements and therefore do not use list/typing.List nor dict/typing.Dict
Describe the solution you'd like
An option that would use typing.Sequence instead of typing.List and typing.Mapping instead of typing.Dict
If use_standard_collections option is set, then import from collections.abc instead of typing
Describe alternatives you've considered
In my feature branch I have a post-generation step that modifies the output file
Additional context
Soon, every Datadog Agent integration will use this to generate models for user configuration 馃檪
@ofek
Thank you for suggesting this feature.
Looks Good!!
I will implement it when I get the time.
Soon, every Datadog Agent integration will use this to generate models for user configuration 馃檪
Wow, it's excellent news. 馃コ
May I write the use-case in the README/documentation after you release it?
May I write the use-case in the README/documentation after you release it?
Sure!
@ofek
I have released a new version 0.7.3
The version has --use-generic-container-types
Amazing, thank you very much!!! I'll comment here when my PR gets merged 馃檪
https://github.com/DataDog/integrations-core/pull/8675 is merged and I've started the syncing of every integration: https://github.com/DataDog/integrations-core/pulls 馃槃
@ofek
It's great!! 馃帀
Do you use OpenAPIParser directly here?
https://github.com/DataDog/integrations-core/blob/85d693ffa317c20c7e623a17c299e6ea137a5a35/datadog_checks_dev/datadog_checks/dev/tooling/specs/configuration/consumers/model.py
I will keep the result of OpenAPIParser().parse().
But, I will refactor the low-level function because the current version doesn't reach 1.0
If you get any problem, then please tell me it.
Also, I can add unittest or integration test to your project.
Thank you
Yes we use that directly. I'll let you know if we encounter any issues, thank you!
Most helpful comment
https://datadoghq.dev/integrations-core/meta/config-models/