-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add azure openai support #214
Conversation
Codecov Report
@@ Coverage Diff @@
## master #214 +/- ##
==========================================
+ Coverage 72.51% 73.44% +0.92%
==========================================
Files 21 21
Lines 593 625 +32
==========================================
+ Hits 430 459 +29
- Misses 124 125 +1
- Partials 39 41 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, there is one authorization that needs to be revised. Also the /chat/completions API does not exist for the current stable API version api-version
authorization for non stream request just fixed. about the /chat/completions API, we are using the what can we do about the |
stable API version 2022-12-01 This API includes a prompt field, if we want to support it, we can just deal with this field. Or we can just declare we only support 2023-03-15-preview api version |
currently, I follow the yes, this is simple and just works. if c.config.APIType == APITypeAzure {
// use api-key method
} else {
// user bear token
} I think maybe it is better to add a like type AuthMethod interface {
SetupAuth(req *http.Request, apiKey string)
} then impl two common : type GenericApiKeyAuth struct {
KeyName string
}
func (a *GenericApiKeyAuth) SetupAuth(req *http.Request, apiKey string) {
req.Header.Set(a.KeyName, apiKey)
}
type BearTokenAuth struct{}
func (a *BearTokenAuth) SetupAuth(req *http.Request, apiKey string) {
req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", apiKey))
} and we can have the default:
|
maybe it 's simple just declare we only support 2023-03-15-preview api version ? after all, and, even |
Thank you so much for the PR! |
A couple of general comments:
We are actively avoiding this style of configuration as discussed in #79.
While making this package close to python's would be a good thing, it is less of a priority than not breaking API for existing clients. I don't think renaming |
|
just add error check for seems there's other thing need fix:
|
Exactly, there are multiple common ways to pass the configuration, this library prefers using a single config struct.
This PR checks for three errors:
if cfg.APIKey == "" {
return ClientConfig{}, fmt.Errorf("api key is required")
}
if _, ok := supportedAPIType[cfg.APIType]; !ok {
return ClientConfig{}, fmt.Errorf("unsupported API type %s", cfg.APIType)
}
if cfg.APIType == APITypeAzure || cfg.APIType == APITypeAzureAD {
if cfg.APIVersion == "" {
return ClientConfig{}, fmt.Errorf("an API version is required for the Azure API type")
}
} |
OK. try to fix the PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for re-working this PR, it is much more manageable now! I've added a couple of comments — I wonder what your thoughts are
config.go
Outdated
|
||
HTTPClient *http.Client | ||
APIType APIType | ||
APIVersion string // required for APITypeAzure or APITypeAzureAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can also pack Azure-related fields into a sub-structure inside the config? That way, it would be more straightforward during configuration:
config.APIVersion = ...
config.Engine = ...
vs
config.Azure.APIVersion = ...
config.Azure.Engine = ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do this to Azure, do we have to make a special openai
config for openai?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the py default the version to 2023-03-15-preview
, we do this the same ?
api_version = (
"2023-03-15-preview" if api_type in ("azure", "azure_ad", "azuread") else None
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done via 84ea881
since this func called DefaultXXX
, I think is OK to do this.
43c417d
to
60cafde
Compare
Excellent, ready to merge once codecov issues are fixed 🙌🏻 |
…uto trim suffix /
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, thank you!
feat: add azure openai support
refactor config:1. addWithXXX
options, allow construct a config likeopenai.NewConfig(...Option)
2. make the config field naming more like theopenai
python pkg's, this will make us follow py's changes more easy3. add newNewConfig
method, which will check the config just like the py' pkg (the error message almost the same)resolve #142