A Swift NIO MQTT v3.1.1 and v5.0 Client
Swift implementation of JMESPath, the JSON query language
Generate a signed URL or Request headers for submitting to Amazon Web Services.
Compression/Decompression support for Swift NIO ByteBuffer
adam-fowler/s3-filesystem-kit 6
Swift File Manager for AWS S3
adam-fowler/sns-to-slack-lambda 5
Swift Lambda for publishing SNS messages to Slack
iOS MQTT Client using MQTTNIO library
adam-fowler/ses-forwarder-lambda 2
Swift based SES email forwarding lambda
adam-fowler/dictionary-encoder 1
Swift Dictionary Encoder, based off the JSON Encoder in Foundation
adam-fowler/localstack-awscli 1
Use for testing localstack in a GH action
push eventsoto-project/soto-core
commit sha d9e34897534398acdfb8ed2e2ee971634426fb24
Use async/await versions of code when testing AsyncSequence
push time in 13 hours
push eventsoto-project/soto-core
commit sha 849089c0ee9ecd037e1b8d5b58cda2668849c10f
Add checkCancellation before http request to AWS
push time in 13 hours
push eventsoto-project/soto-core
push time in 17 hours
push eventsoto-project/soto-core
commit sha f476167cf4e1cd1fcbdaad10db32ed539fc200ba
kick off GH action
push time in 17 hours
push eventsoto-project/soto-core
commit sha bf0c39854270958a82245b4f68197cc9ed334b90
comment
push time in 17 hours
issue openedapple/swift-nio
Add a generic connection error for NIO
Currently NIOConnectionError is part of NIOPosix. If I am wanting to write a platform agnostic NIO package and respond to connection errors there is currently no way to do this without importing NIOPosix and then of course you are only responding to connection errors from NIOPosix.
Could we have a generic connection error that holds the original platform specific error . Something like (I know this is a name clash)
struct NIOConnectionError: Error {
let error: Error
}
I'm guessing this would be a breaking change as functions would be throwing a new error type. Maybe something for NIO3.
created time in 18 hours
PR opened soto-project/soto-core
This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.
pr created time in 18 hours
PR closed soto-project/soto-core
This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.
pr closed time in 18 hours
PR opened soto-project/soto-core
This adds AWSPayload.asyncSequence which allows you to provide an AsyncSequence of ByteBuffers to a request.
pr created time in 18 hours
push eventsoto-project/soto-core
commit sha 9965f427bbb899660714736effa2bad9a85b1b27
Add AWSPayload.asyncSequence
push time in 18 hours
push eventsoto-project/soto-core
commit sha da2b55d750bd00fb2d79b9e629c9c04bdd1bd17b
Replace import NIO with import NIOCore (#459) * Replace import NIO with import NIOCore Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point * swift format
commit sha c404fe18a839ca62522df961a1602bde58732ea5
Add EventLoopFuture.get() async
commit sha 2166c189695337d1371b8036cac308b3cf677411
Add async interfaces for AWSClient
commit sha 3226af0cd930d527fb35fc69b1da6ebcf2216e8e
Add tests for async interfaces
commit sha 75e402bd3491f5997f36ca84605bde72dc329130
Use runAsyncAndBlock
commit sha 14bc1d352952253bc0a2ac067bce004592816854
Add PaginateSequence
commit sha 992cdecbc95fd6e377a7d9c0b22a19b75abc8171
Add signURL async versions
commit sha 0e083d03606894cd8279bf9d0393d9517f1bddc8
Update AWSClient.execute async for new stream flag
commit sha d551ef199034415234785066eb85ca0438dbc9b3
Add #if compiler(>=5.4) && $AsyncAwait tests
commit sha ead146f115b8de9bc37fe8d3a878c37b983e6f84
Make inputKey optional in paginator, add optional moreResultsKey
commit sha 050a7f9e135503afda9348e593aee2b7e52c7bfc
Use nightly builds of swift for CI
commit sha cb1b7288425d254a2c27e61ee1a520518a57480d
Wrap everything with @available(macOS 9999, etc)
commit sha e0bf432eb5c7fbfd29a558db26d72d4fd18191c2
Use versions of reduce from swift code with rethrows replaced
commit sha f1a2c23cbf95c6056ed71347a4bc0b47f6ddf2ad
Added `AsyncCredentialProvider`
commit sha 07ecdda0951b8f1906535d1d23e915f55bfbb544
Tidying up Remove all experimental concurrency features Split concurrency tests into separate files Use group.next() in tests Revert GH actions to main branch versions
commit sha 0b5014d90003e94db045cbe77d421ab9536066fb
Move paginate async tests into their own class Fixup Tests Fix AWSClientAsyncTests This isn't popular for try await _ in group {} Add swiftlang/swift:nightly-focal to CI to test async code Disable async tests as they crash thread sanitizer
commit sha fe94ea02fb27857c8432e04ac809f17eccb5d8e3
Replace custom async code with _NIOConcurrency versions
commit sha 374a4b709ee1472d8d66756e91da6de24711118f
Updated for latest async/await syntax changes Remove reduce implementations, as rethrows works on protocols now
commit sha e79d61eb7673008be6cf5fbabc75ec3034d50d84
Add AsyncCredentialProviderTests
commit sha 0df7402accb1c3755a27699b162f0429e68f1262
Update available version numbers Swap out swift version for swift nightlies Remove $AsyncAwait test
push time in 19 hours
push eventsoto-project/soto
commit sha db8d1d07be8daceb43010ce291264f54ca1528e9
Replace NIO with NIOCore where applicable (#526) * Replace NIO with NIOCore where applicable * Fix S3Tests
push time in 20 hours
pull request commentsoto-project/soto
Replace NIO with NIOCore where applicable
Cool as long as it's something we export that should be fine. My thinking was to avoid headaches in the future when SwiftPM fixes the bug of making all targets in the dependency tree available to everything at some point in the future
I'll look into this in another PR maybe
comment created time in 20 hours
pull request commentsoto-project/soto
Replace NIO with NIOCore where applicable
LGTM. The only thing I don't see is adding
NIOCoreas a dependency in the manifest - was this done previously or are you relying on SwiftPM exposing that to you via NIO's exports?
I guess the services that include the import NIOCore/NIOPosix should really have the dependency in the manifest. It's a bit of a pain, when you are autogenerating the Package.swift. In most cases I could actually remove the import NIOCore as I have @_exported a number of the NIOCore symbols from SotoCore.
comment created time in 20 hours
push eventsoto-project/soto
commit sha a51e7d73988ab536e5fa94846b82f30d06f9c462
Fix S3Tests
push time in 20 hours
PR merged soto-project/soto-core
Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point
pr closed time in a day
push eventsoto-project/soto-core
commit sha da2b55d750bd00fb2d79b9e629c9c04bdd1bd17b
Replace import NIO with import NIOCore (#459) * Replace import NIO with import NIOCore Needed to add a couple of import NIOPosix calls as well, hopefully can remove those at some point * swift format
push time in a day
pull request commentswift-server/guides
Swift Concurrency adoption guidelines for Swift Server Libraries
- [ ] example with async sequence
Soto has an AsyncSequence sample used for paginated results. It is full of generics so might not be the simplest example though. https://github.com/soto-project/soto-core/blob/async-await/Sources/SotoCore/AWSClient%2BPaginate%2Basync.swift
comment created time in a day
Pull request review commentswift-server/guides
Swift Concurrency adoption guidelines for Swift Server Libraries
+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+ func work() -> EventLoopFuture<Value> { ... }+ + #if swift(>=5.5)+ func work() async throws -> Value { ... }+ #endif+}+```++If a function cannot fail but was using futures before, it should not include the `throws` keyword in its new incarnation.
Given most implementations will be using EventLoopFuture.get initially everyone will be forced into adding throws
comment created time in a day
Pull request review commentswift-server/guides
Swift Concurrency adoption guidelines for Swift Server Libraries
+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+ func work() -> EventLoopFuture<Value> { ... }+ + #if swift(>=5.5)+ func work() async throws -> Value { ... }+ #endif+}+```++If a function cannot fail but was using futures before, it should not include the `throws` keyword in its new incarnation. ++Such adoption can begin immediately, and should not cause any issues to existing users of existing libraries. ++### SwiftNIO helper functions++To allow an easy transition to async code, SwiftNIO offers a number of helper methods on `EventLoopFuture` and `-Promise`. Those live in the `_NIOConcurrency` module and will move to `NIOCore` once Swift concurrency is released.
Is the module keeping the _ prefix even after swift 5.5 release?
comment created time in a day
Pull request review commentswift-server/guides
Swift Concurrency adoption guidelines for Swift Server Libraries
+# Swift Concurrency adoption guidelines for Swift Server Libraries++This writeup attempts to provide a set of guidelines to follow by authors of server-side Swift libraries. Specifically a lot of the discussion here revolves around what to do about existing APIs and libraries making extensive use of Swift NIO’s `EventLoopFuture` and related types.++Swift Concurrency is a multi-year effort. It is very valuable for the server community to participate in this multi-year adoption of the concurrency features, one by one, and provide feedback while doing so. As such, we should not hold off adopting concurrency features until Swift 6 as we may miss valuable opportunity to improve the concurrency model.++In 2021 we saw structured concurrency and actors arrive with Swift 5.5. Now is a great time to provide APIs using those primitives. In the future we will see fully checked Swift concurrency. This will come with breaking changes. For this reason adopting the new concurrency features can be split into two phases.+++## What you can do right now++### API Design++Firstly, existing libraries should strive to add `async` functions where possible to their user-facing “surface” APIs in addition to existing `*Future` based APIs wherever possible. These additive APIs can be gated on the Swift version and can be added without breaking existing users' code, for example like this:++```swift+extension Worker {+ func work() -> EventLoopFuture<Value> { ... }+ + #if swift(>=5.5)+ func work() async throws -> Value { ... }
Is it worth adding the @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)?
comment created time in a day
push eventadam-fowler/jmespath.swift
commit sha dfefd85537f15ad44f211d9fdacb89e21ed0de31
Remove unnecessary @testable
push time in 2 days