Beta Feedback and Feature Requests!

[ms-jpq]

General discussion for beta feedback and feature requests

• Collection for general feedback and feature requests so we can prioritize.

• Please feel empowered to start a new issue for more substantial areas of discussion.

• Prioritization will be adjusted in accordance with community interest.

Current priorities

Lazy Loading

• Users should be able to use this gem in say Rails, without explicit require "openai"

[jankeesvw]

I noticed that there is another gem called openai, are you working on this? When I follow the steps in the readme install that gem. I installed this gem with: gem "openai", github: "openai/openai-ruby"

[ms-jpq]

hi @jankeesvw, sorry about that 😅, that gem is not currently under the OpenAI domain, and I should have added a little spiel at the top of the README.

late edit: fixed

[agarcher]

I'm having a trouble getting the gem to load properly in a rails environment. When adding the gem and trying to blindly use it, I was getting NameErrors because the OpenAI namespace wasn't initialized (the gem wasn't auto-loaded). I was able to workaround this with a require "openai" statement in application.rb or by creating an initializer with the require that also accessed the constant (a noop call to OpenAI which is kind of weird). I think the second workaround stopped working with the latest changes since yesterday.

However, these workarounds don't solve the loading issues when tapioca tries to load the rails application to build rbis.

❯ bundle exec tapioca dsl                                                                                                                             Loading DSL extension classes... Done
Loading Rails application...
Tapioca attempted to load the Rails application after encountering a `config/application.rb` file, but it failed. If your application uses Rails please ensure it can be loaded correctly before generating RBIs. If your application does not use Rails and you wish to continue RBI generation please pass
 `--no-halt-upon-load-error` to the tapioca command in sorbet/tapioca/config.yml or in CLI.
uninitialized constant OpenAI
bundler: failed to load command: tapioca (/Users/agarcher/.rbenv/versions/ruby-3.3.0/bin/tapioca)
...

The rest of the error just shows the first place in my application that it hits a reference to the OpenAI namespace, which is a schema class I define that extends OpenAI < BaseModel

Any suggestions for how to properly load the gem in a rails environment?

I tried adding require "bundler/setup" as well, as per the usage instructions, but it didn't help.

[ms-jpq]

hi @agarcher, thank you for the bug report! We are lacking lazy loading currently for this gem, and that is on the road map.

The issue you are running into is actually an interaction of this tapioca bug Shopify/tapioca#2248 and its workaround here:

openai-ruby/lib/openai.rb

Line 19 in a8af268

if Object.const_defined?(:Tapioca) && caller.chain([$PROGRAM_NAME]).chain(ARGV).grep(/tapioca/)

.

When this gem detects tapioca's introspection phase where the tool examines our library's code, it essentially bails out of that process, since the introspection can lead to inaccuracies in terms of the RBI generated. ( which has less resolution than the ones we ship with this library )

This workdaround is obviously not ideal and I did not expect the poor interaction with running tapioca dsl. Before I can push up a more comprehensive fix. Would you be able to try the following potential workaround?

module OpenAI

end

require "openai"

[agarcher]

@ms-jpq this gets messy quickly because I also reference OpenAI::BaseModel OpenAI::ArrayOf, etc. etc. I would need to define stubs of these classes, and I would need to do them only when running tapioca (so I don't conflict with the real gem at runtime). If I'm understanding correctly, it seems like you only need the workaround when the user is running tapioca gem? Perhaps the grep on the workaround could be more specific?

[ms-jpq]

Ah, yeah I see. Humm. I will have to sit down and iterate on this a little bit before I can push up a better workaround. It seems really plausible that could work!

It just feels really bad having to do this in the first place though. In anycase, thank you so much for providing the context & debugging it! 🫶

[agarcher]

@ms-jpq I came up with a more targeted solution in a fork that seems like it is working for me. I opened a PR: #149

[agarcher]

Now that I've got the gem working with the above workaround, I confirmed my fear that while this helps define the JSON schema for my structured responses, it doesn't help me work with the actual response objects I get back as the message.parsed function in the response just gives me a T.anything.

What it actually gives me is an instance of the schema I passed, which has functions for accessing everything defined in the schema. This experience is wonderful, but what's missing is a tapioca compiler that generates RBI files for my schemas so I can pass around instances of the schema classes.

I would be perfectly happy with type assertions for the T.anything objects I get back if the schema classes themselves at least wound up type safe. Are there any plans to support something like this?

[agarcher]

I was able to build a tapioca compiler in our application that is generating us RBIs for our OpenAI::BaseModel subclasses. It depends on some internals and generalizes the enums a bit since sorbet won't allow us to stick literals in the type definitions (which is how enums work in the DSL). I also had to work around a bug where to_sorbet_type was erroring when I called it for enums that referenced Symbols.

Hopefully the implementation can help inspire a solution that can be shipped with the gem.

https://gist.github.com/agarcher/773fff417436be22208db928227aac07

[ms-jpq]

I also had to work around a bug where to_sorbet_type was erroring when I called it for enums that referenced Symbols.

just came back from long weekend, this bug will be fixed ASAP 👍 , along with the tapioca loading issue.

---

edit: fix is in next release https://github.com/openai/openai-ruby/pull/150/files

cc @agarcher

[ms-jpq]

Now that I've got the gem working with the above workaround, I confirmed my fear that while this helps define the JSON schema for my structured responses, it doesn't help me work with the actual response objects I get back as the message.parsed function in the response just gives me a T.anything.

I think we can perhaps use generics to get this properly working 👍, not a terribly high PRI for me at the moment, since we have higher level streaming helpers on the way, but it should come some time after :D, and yeah in the main time a cast would work