Closed ifsheldon closed 1 year ago
It sounds like it would have been easier if you sent PR to this repo instead.
Contributions are welcome!
I was about to, but I didn't want to make a PR that adds a feature without proper discussion, which is rude from my view.
There are a couple of issues:
Serialize
as well? It just a convenient derive, but should we?OpenAIConfig
are optional. To make them optional in deserialization, we need to change them to Option<String>
, so this change leads to broader impacts I guessI will make a PR, though.
Thank you for elaborating.
I think there is no downside to adding Serialize
as well - at least you'll have the machinery to read from and write to config files without introducing any breaking change like making fields Option
al - just that all the fields can be stored in config file to later Deserilaize
.
If the semantics of required-fields and optional-fields are required in config file then you're welcome to send follow up PR - we'll just have to do a version bump for breaking change.
Please add
Deserialize
derive toOpenAIConfig
andAzureConfig
. I store my Azure configs in a json file for testing. WithoutDeserialize
, I need to copy a same struct and addDeserialize
for it and convert it toAzureConfig
, which is unnecessarily verbose.