You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the SDK is modularized, fine-grained decisions will need to be made about what packages are needed as dependencies for a given service within the SDK. For instance:
What AWS protocol does the service use? It might need to link in the XML or alternately the JSON serialization modules.
What auth schemes does it use? Different auth schemes might be modularized separately.
Does it use streaming? Checksums? DNS?
(Several of these conditions are laid out in Smithy Reference Architecture's Modularization section.)
With the current Swift-based package manifest generator which runs after codegen is complete, it is impossible to determine these conditions easily since it does not integrate with Smithy and does not have access to Smithy model info. The Swift-based package manifest generator works okay when all services have the same dependencies, but does not have the necessary context once services have more customized dependency graphs.
The natural solution to this problem is to generate the Package.swift along with the other generated code, in the smithy-swift Kotlin project. (There is already code for generating Package.swift in the project that is currently unused; this may serve as a useful starting point.)
This should be used for generating the protocol test Package.swift as well.
Use Case
To support modularization of the SDK.
Proposed Solution
No response
Other Information
No response
Acknowledgements
I may be able to implement this feature request
This feature might incur a breaking change
The text was updated successfully, but these errors were encountered:
Describe the feature
Note: this is a subtask of Modularization.
As the SDK is modularized, fine-grained decisions will need to be made about what packages are needed as dependencies for a given service within the SDK. For instance:
(Several of these conditions are laid out in Smithy Reference Architecture's Modularization section.)
With the current Swift-based package manifest generator which runs after codegen is complete, it is impossible to determine these conditions easily since it does not integrate with Smithy and does not have access to Smithy model info. The Swift-based package manifest generator works okay when all services have the same dependencies, but does not have the necessary context once services have more customized dependency graphs.
The natural solution to this problem is to generate the Package.swift along with the other generated code, in the smithy-swift Kotlin project. (There is already code for generating Package.swift in the project that is currently unused; this may serve as a useful starting point.)
This should be used for generating the protocol test Package.swift as well.
Use Case
To support modularization of the SDK.
Proposed Solution
No response
Other Information
No response
Acknowledgements
The text was updated successfully, but these errors were encountered: