Updates for new OpenAI release post dev day

[transitive-bullshit]

• adds support for tools
• changes some other types required by openai updates

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dexter	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 9, 2023 2:23am

[transitive-bullshit]

It seems like the legacy functions have the same structure and function, but are now nested under tools. I think all of the schema/spec/parser/implementation parts of AIFunction should stay the same (without tools) and should be used by a new higher level tools abstraction that is just wraps a function for now, and presumably other things in the future.

Sounds good & agreed. I haven't actually used createAIFunction yet, so that would be a good first step haha

Also, can you please start writing real commit messages :)

Yep; sorry about that. I try to use real git-flow commit messages for substantive stuff and commit-emoji for minor things. Will work on breaking that habit for dexa stuff. :)

[transitive-bullshit]

This PR is now dependent on https://github.com/dexaai/openai-fetch/pull/38

[transitive-bullshit]

@rileytomasek I changed the tools and function assistant types and utility functions to have an explicit assistant prefix.

I also fixed all the lingering TS issues, mainly due to the message stuff. Such a PITA.

Not 100% sure I incorporated the assistant prefix feedback you gave as you were expecting. Happy to adjust.

[transitive-bullshit]

This looks good other than the name changes. Can we hold off removing the Message.name stuff until everything settles from the new releases and it's clear what the status of name is? We're using it internally and I'd rather not change until we know it's definitely gone.

Done.

Edit: these changes are also going to require a major version bump, right?

Yes, though it's a brand new package, so we could just do a minor? I'm fine either way.

[transitive-bullshit]

Fixes https://github.com/dexaai/dexter/issues/8 as well

[rileytomasek]

Everything looks good, except for the names I suggested 😂

What do you think of:

System
User
Assistant
FuncCall
FuncResult
ToolCall
ToolResult

And then mirror to Msg methods like:

Msg.system()
Msg.user()
Msg.assistant()
Msg.funcCall()
Msg.funcResult()
Msg.toolCall()
Msg.toolResult()

Msg.isSystem()
Msg.isUser()
Msg.isAssistant()
Msg.isFuncCall()
Msg.isFuncResult()
Msg.isToolCall()
Msg.isToolResult()

[transitive-bullshit]

Everything looks good, except for the names I suggested 😂

What do you think of:

System
User
Assistant
FuncCall
FuncResult
ToolCall
ToolResult

And then mirror to Msg methods like:

Msg.system()
Msg.user()
Msg.assistant()
Msg.funcCall()
Msg.funcResult()
Msg.toolCall()
Msg.toolResult()

Msg.isSystem()
Msg.isUser()
Msg.isAssistant()
Msg.isFuncCall()
Msg.isFuncResult()
Msg.isToolCall()
Msg.isToolResult()

I'm not opinionated when it comes to naming; the only problem I see w/ this is that ToolCall type represents both the individual tool call { id: string, type: string, function: FunctionCall } as well as the tool call message type, which represents an array of tool calls.

It's the same issue w/ FunctionCall type except you got around that by shortening the message function call type to FuncCall to avoid the naming collision.

I don't have a strong feeling either way.

[transitive-bullshit]

If we call the tool calls message ToolCalls or ToolsCall, that would get around it. ToolsCall sounds better, but it's weird for the underlying field to be tool_calls and then refer to it as a ToolsCall...