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!

[mergesort]

Hi @jamesrochabrun, I finally had some time to explore this and came up with a simple solution.

This change looks like a monster, but for the most part it's just spacing changes, because as best I can tell your project seems to use 3 space tabs versus most 2 or 4 space configurations.

In reality all this change does is:

• Swaps in AsyncHTTPClient for URLSession. This is becoming a standard in most multi-platform projects I've seen, because URLSession is horribly broken on Linux.
• The one exception is anything related to AIProxy. I've left everything alone there as best as I can, and simply do not compile the code on Linux, since AIProxy does not make much sense to use in a server environment where API requests are already protected.

If you think this is a good path forward and would be willing to accept a PR, I would be very happy to clean this up to your liking, I really would love to use this on Linux. (I can also do the same for SwiftAnthropic if you'd be ok with it, I really would love to be able to use that as well.)

Please let me know, and thanks again for all your work on this great library!

[gsabran]

@mergesort could you create a PR? I was talking with @jamesrochabrun. Your change overall looks great, but we were hesitant to migrate everyone off URLSession that for all its issues is a reliable workhorse on non linux platforms. Do you think you could make URLSession conform to the new HTTPClient protocol, and default non linux users to that existing implementation, so that this change is transparent to them?

FYI I just made #141 that'll make spacing consistent. You probably want to cherry-pick 603e32c and run the linter on your end to avoid massive merge conflicts.

[mergesort]

That's a great idea, conforming URLSession to HTTPClient is better than the what I had in mind! I'll start from scratch with the new spacing and clean up everything, then file a PR for review.

[mergesort]

Done in #143, let me know what you think!