since you read this, there's a good chance you either are using Thrift already, or are at least interested in the topic to some degree.
For several months we noticed that the CI builds for Swift are broken and there are no more Swift patches or pull requests coming for a long time. This raises the question if there is any public interest left in maintaining the Apache Thrift Swift bindings any further, or whether the Swift community maybe already switched over to alternative libraries like [1]?
Although I created this ticket [2] yesterday, I would be more than happy to close it myself as "won't fix" if there would be someone stepping up anf finally becoming maintainer (and committer) for the Swift bindings. I want to emphasize that this is by no means limited to one person, quite the opposite. To keep things alive and moving forward, having multiple maintainers for a given target language around is a great advantage in many ways.
If, however, there is no active maintainer anymore and no longer any interest within the Swift community, we may be forced to draw the conclusion and drop Swift support from the codebase. At this time, it is still just an option to be taken into consideration, not a final decision.
Feel free to contact us via the Thrift "dev" mailing list (dev AT thrift.apache.org).
Part of what the SSWG does is try to maintain longlevity of projects such as these, even though we didn't "incubate" this one in our process Thrift is a great project so it's sad do see the Swift support has fallen behind like that.
A quick look seems like the issues are not that drastic, but of course I understand you'd like to find some committed maintainer rather than a one off fix here.
Please give us a while so we can check for some active users and potential maintainers which may be interested to step up here. We'll report back as soon as we can, thank you for letting us know about this.
If anyone in the community on the forums is interested please chime in as well, thank you!
The logs have expired on GitHub so I can’t see what was going wrong with the build.
Right, for some unexplainable reason I never copied the message, indeed.
However, if you revert that patch below and send a PR that should bring it back at that PR:
I just compiled the Parquet schema using Thrift and I’m getting the feeling this would be a huge amount of work. I’m seeing a lot of errors - the Thrift runtime and compiled code are matched, but even with a lot of manual experimentation I couldn’t the generated schema close to compiling. It looks like it would be a significant re-engineering effort, involving both the compiler and the runtime.
Another thing is I’m keen to use swift-binary-parsing for any parser I work on. It’s well supported and performance optimised, but the main advantage is there’s a memory-safe and overflow-safe parser for almost every primitive. Second it’s possible to build very composable parsers.
I’ve already retrofitted this into ios-twitter-apache-thrift to parse Parquet metadata, and I added LEB128 integer support to swift-binary-parsing partly to support compact Thrift [1]. Short term I’m going to use this approach.
Longer term, I wonder if there’s a way for these two approaches to be reconciled - i.e. leverage swift-binary-parsing, but use the Thrift compiler approach.
Apologies for deleting my previous message - I thought nobody had seen it and I was having second thoughts after having seen the problems with the compiled Parquet schema.
There is also a big issue with the state of Swift in the Apache ecosystem: Currently there is only one approved [1] github action for Swift CI and this has been abandoned for six months [2]. It currently fails with intermittent GPG errors. There has been a fix available for a while [3] but I have little hope this will get merged.
It is a sad state of affairs indeed. I’m currently putting a lot of effort into getting Arrow Swift into a usable state, however this is often blocked by failing CI. Pull request routlette isn’t much fun !
Hmm, if that's the case--separately from fixing those issues--I wonder if it might be beneficial to pursue approving the use of the official github actions all the swiftlang projects are using for CI? They're very actively maintained by the actual Swift team, whilst the install-swift action isn't
The issue in install-swift is also a problem of course that's worth fixing... but using the above ones as a higher chance of keeping working long term I think
I have asked the owner of setup-swift for comment on the maintenance status [1] but I think you’re right, using the official github actions seems like the right course of action. I’m not certain what the process for that is, but I’ll look into it.
