-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Commands: add experimental-destination
command
#5911
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
Conversation
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
usesLenientParsing: true | ||
) | ||
|
||
guard version <= Version(1, 1, 0) else { |
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 think this pattern is a bit nicer: https://github.com/apple/swift-package-manager/blob/main/Sources/Workspace/Workspace%2BState.swift#L105
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
Hm, I'm not sure it makes sense to have a new subcommand of |
Ah, great point. This was supposed to be a top-level command, but I didn't know one could be created without automatically being added to the installation list. And then Thanks for the suggestion, I'll move it to the top level. |
@neonichu WDYT of @tomerd also interested in your opinion on this. |
consistency is good. we should run this by the community as part of the pitch |
Thinking about it more, would it make more sense to install the new top-level tool after all, just keeping it named |
Confirmed with @tomerd that he's fine with keeping this as a subcommand of If/when it goes through an evolution proposal, we can graduate it to a top-level command. This is ready for review then. |
} | ||
} | ||
} | ||
|
||
fileprivate var dotSwiftPMCrossCompilationDestinationsDirectory: AbsolutePath { | ||
get throws { | ||
return try self.dotSwiftPM.appending(component: crossCompilationDestinationsDirectoryName) | ||
return try dotSwiftPM.appending(component: crossCompilationDestinationsDirectoryName) |
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.
Not sure this feels right. I think on macOS, we probably want this to be inside ~/Library/Application\ Support/org.swift.swiftpm
and not sure what a canonical place for other OSes would be.
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'm modeling this after all other path options boilerplate, for which a symlink is created to idiomaticSwiftPMDirectory
where possible.
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.
Sure, but isn't the primary location ~/Library/org.swift.swiftpm
right now?
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.
That's correct. Is your point that dotSwiftPMCrossCompilationDestinationsDirectory
property should be deleted altogether? It's only called from swiftPMCrossCompilationDestinationsDirectory
, which checks if ~/Library/org.swift.swiftpm
is a valid path on the host platform and prefers that one.
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 was wondering whether these should be in "Application Support" instead since they're more "data" than "configuration", but now looking at it, we should probably not have a ~/Library/org.swift.swiftpm
in the first place, but rather place things into subdirectories of "Preferences" and "Application Support"? Let's not worry about it for this PR.
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 still think it's wrong to break the meaning of swift package
, even for an experimental use case, but the changes themselves look good to me.
Figuring out the exact storage location is also something we could leave for the proposal review.
Do you think there's any other existing command we could use instead? Or would you still prefer this to be an installed top-level experimental command? |
Also adds `experimental-destination list` subcommand, which prints a list of available destinations. `ArtifactsArchiveMetadata` schema version validation is implemented to accept new 1.1 schema version with the new destinations bundle type.
13ec06e
to
23e8991
Compare
@swift-ci please smoke test |
@neonichu would you mind having another look after I made it a top-level command? I only want to make sure I didn't miss anything on that front. |
Also, I didn't add a |
Would we want it to be available on Windows? That is only using the CMake build so anything not covered by it won't be available there. |
Hm, I thought Windows builds only the bootstrap tool with CMake and then builds the rest with SwiftPM, doesn't it? Either way, it's of no use for Windows at the moment, we don't have generator code for Windows as a host platform yet. |
Motivation:
Also adds
experimental-destination list
subcommand, which prints a list of available destinations. Subcommands that allow adding and removing destinations will be added in future PRs.Modifications:
New
DestinationCommand
andListDestinations
types are added, conforming toParsableCommand
. They don't conform toSwiftTool
, so the new subcommand can be invoked in an arbitrary directory that doesn't contain aPackage.swift
manifest.ArtifactsArchiveMetadata
schema version validation is implemented to accept new 1.1 schema version with the new destinations bundle type.Result:
swift experimental-destination list
prints a list of destination bundles with valid metadata in~/.swiftpm/destinations
.