-
Notifications
You must be signed in to change notification settings - Fork 732
Conversation
plugins from a manifest file | ||
""" | ||
|
||
spec_functions = ['describe_plugin'] |
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.
hmm i think the tool spec interface is a bit confusing now that we're overriding to_tool_list
. a bit hard to tell now which tools are actually getting returned to the agent, and the spec_functions
don't quite match anymore
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.
do you have thoughts on how to simplify this?
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.
also, unrelated maybe to this PR but out of curiosity why does the openapi tool take in a pre-existing dict instead of loading the openapi spec as part of the function
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.
Yeah I see what you mean, I think if we wanted to make the interface more intuitive from the code we could:
- Require the user to import and pass the Requests tool spec, similar to what OpenAPI tool spec requires right now.
- have ChatGPT plugin export its own load_openapi_spec that calls the internally wrapped OpenAPIToolSpec, and add it to spec functions
With that we wouldn't need to override to_tool_list and make it potentially a bit easier for users to customize request headers. I think this seems a bit more straight forward, I'll put together some code.
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.
For the openapi tool taking a dict, my thinking was it allows users to load a spec from url or local file, but we could also update the interface to accept a file path or url and load the spec from there. I can't really imagine users wanting to load an OpenAPI spec in a different way.
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.
yeah that's more intuitive, it unbundles loading the spec from actually calling the spec (with the requests tool). We can just treat the chatgpt plugin as a special case of the openapi spec
2dcd5b7
to
4d9a9ab
Compare
4d9a9ab
to
380ce18
Compare
@jerryjliu Fixed up the openapi spec to accept a url or a spec, and same with the ChatGPT plugin. Also simplified the interface as we discussed. |
3d92e5c
to
2919485
Compare
@@ -41,6 +45,10 @@ | |||
"id": "tools/slack", | |||
"author": "jerryjliu" | |||
}, | |||
"TextToImageToolSpec": { |
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.
Tag along fix because I missed adding this in the initial text to image PR
A tool that allows you to easily load a ChatGPT Plugin from a manifest file, leveraging the OpenAPI tool spec and Requests tool specs.