- Notifications
You must be signed in to change notification settings - Fork 1.4k
Add Swift SDK target triples to swift sdk subcommands #9036
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| | @@ -202,6 +202,7 @@ public final class SwiftSDKConfigurationStore { | |||||
| } | ||||||
| | ||||||
| if showConfiguration { | ||||||
| print("\nswiftSDK: \(targetTriple)") | ||||||
| Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is the key called Suggested change
Member Author There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point, I chose to stick with the currently used terminology, as the command to actually use the SDK is I simply followed the language they used, so as not to confuse users. However, I now see that the Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please do change this to triples, this is an opportunity to clean this up in preparation for Swift SDK aliases. | ||||||
| print(swiftSDK.pathsConfiguration) | ||||||
| continue | ||||||
| } | ||||||
| | ||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| | @@ -45,6 +45,7 @@ struct ShowConfiguration: ConfigurationSubcommand { | |||||
| _ swiftSDKsDirectory: AbsolutePath, | ||||||
| _ observabilityScope: ObservabilityScope | ||||||
| ) throws { | ||||||
| print("\nswiftSDK: \(targetTriple)") | ||||||
| Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto Suggested change
Member Author There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as above. | ||||||
| print(swiftSDK.pathsConfiguration) | ||||||
| } | ||||||
| } | ||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| | @@ -50,8 +50,15 @@ package struct ListSwiftSDKs: SwiftSDKSubcommand { | |||||
| return | ||||||
| } | ||||||
| | ||||||
| for artifactID in validBundles.sortedArtifactIDs { | ||||||
| print(artifactID) | ||||||
| let swiftSDKBundles = validBundles.listSwiftSDKs(hostTriple: hostTriple) | ||||||
| for bundle in validBundles.sortedArtifactIDs { | ||||||
| if let targetTriples = swiftSDKBundles[bundle], !targetTriples.isEmpty { | ||||||
| print("Swift SDK bundle: \(bundle)") | ||||||
| print("Swift SDKs:") | ||||||
| Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Suggested change
Member Author There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On this one I disagree, for the reasons given above, ie users are going to just use the Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Retrospectively, enabling use of triples as arguments for Member Author There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, if I'm gating this behind a flag anyway, I can change the label too. | ||||||
| for triple in targetTriples { | ||||||
| print(" \(triple)") | ||||||
| } | ||||||
| } | ||||||
| } | ||||||
| } | ||||||
| } | ||||||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this meant to be adopted outside of SwiftPM? If not, it shouldn't be
public. Also, please add a doc string to the function declaration to clarify if host triples or target triples are returned.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simply followed what the sorted list of
sortedArtifactIDswas doing above by making itpublic, as I felt this was more useful than that, will add the doc.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Existing code shouldn't be used as precedent for selecting access control for new code. There's a very high bar for introducing new public APIs in SwiftPM, as evolving it or removing in the future is a high maintenance cost. Unless we know of the exact use case and client adopting this new API, we should not introduce this as a public API in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that this is so generally useful that it should be a public API, do you disagree?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SwiftPM has been overly generous with providing public APIs over the years, and given that it isn't semantically versioned none of these APIs could be removed or changed without breaking downstream clients, which in itself is very undesirable experience that it makes it very hard to change or refactor anything in the project.
Unless we have an exact client/project/package that we can point to that absolutely needs this API as
publicand doesn't have an alternative way of implementing it, nothing should be madepubliconly because it's "generally useful".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, will change it.