search

jamesrochabrun / SwiftOpenAI

An open-source Swift package for interacting with OpenAI's public API.
MIT License
346 stars 49 forks source link

Serverside / Linux support #89

Open mfreiwald opened 2 weeks ago

mfreiwald commented 2 weeks ago

Any plans to make this buildable on Linux? Since its better to not put your API-keys on the client I want to use this on my swift server project.

I created a fork and replaced URLSession by HTTPClient from async-http-client but it's not fully tested yet and I have no idea yet what is the best approach to make it available for URLSession AND HTTPClient.

jamesrochabrun commented 1 week ago

Not plans at the moment, open for collaborations!

mergesort commented 1 week ago

I was just doing a comparison of OpenAI-compatible packages to integrate into my Vapor app, and came across this project. I've already integrated it into a local tool and think you've got a great API surface, I quite prefer it the ergonomics of this library to the MacPaw OpenAI library. Is there any chance you'd reconsider adding Linux support?

I've helped add Linux networking support to other projects before, and it's not particularly difficult to maintain, after the initial work is done you can automate the process of making sure things still work by building on Linux in a Github Action.

jamesrochabrun commented 6 days ago

Thanks for the interest, I am trying to get the issues as minimum while trying to handle other responsibilities 🙏

But lets see how we can move forward here.

@mfreiwald is it correct to say that this is all we need? https://github.com/jamesrochabrun/SwiftOpenAI/compare/main...mfreiwald:SwiftOpenAI:serverside

Why do we need to remove Sources/OpenAI/AIProxy/AIProxyCertificatePinning.swift

I will like to add more functionality but without sacrificing existing one, please let me know your thoughts, thanks.

mfreiwald commented 6 days ago

No, my solution replaces URLSession completely with AsyncHttpClient. a smaller change would be to adjust the URLSession calls so that they align with ‚FoundationNetworking‘.

I try to find some time in the next two weeks for a better solution including a PR.

mergesort commented 6 days ago

My suggestion would be to not depend on the Linux implementation of URLSession, but to instead continue integrating AsyncHTTPClient. There are many bugs in the Linux implementation of URLSession, not just minor ones, and they will continue to persist now that URLSession is unmaintained in favor of AsyncHTTPClient.

What I would recommend doing is isolating the networking logic, and exposing a common interface that layers over URLSession and AsyncHTTPClient in a way that the rest of your callers never need to think about. This would make it so only one file needs to change a lot, but every other file in your library (and external users) wouldn't have to be concerned with these implementation details.

If that makes sense, I'm happy to talk through this some more!