Serverside / Linux support

[mfreiwald]

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]

Not plans at the moment, open for collaborations!

[mergesort]

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]

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? 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]

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]

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!