Skip to content

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

Merged
merged 6 commits into from
Dec 15, 2022

Conversation

MaxDesiatov
Copy link
Contributor

@MaxDesiatov MaxDesiatov commented Nov 17, 2022

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 and ListDestinations types are added, conforming to ParsableCommand. They don't conform to SwiftTool, so the new subcommand can be invoked in an arbitrary directory that doesn't contain a Package.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.

@MaxDesiatov
Copy link
Contributor Author

@swift-ci please smoke test

1 similar comment
@MaxDesiatov
Copy link
Contributor Author

@swift-ci please smoke test

usesLenientParsing: true
)

guard version <= Version(1, 1, 0) else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MaxDesiatov
Copy link
Contributor Author

@swift-ci please smoke test

1 similar comment
@MaxDesiatov
Copy link
Contributor Author

@swift-ci please smoke test

@MaxDesiatov MaxDesiatov added ready Author believes the PR is ready to be merged & any feedback has been addressed enhancement and removed ready Author believes the PR is ready to be merged & any feedback has been addressed labels Nov 23, 2022
@MaxDesiatov MaxDesiatov requested a review from tomerd November 23, 2022 23:11
@neonichu
Copy link
Contributor

Hm, I'm not sure it makes sense to have a new subcommand of swift package that doesn't actually operate on a package, that's supposed to be the one defining trait of swift package. Should we make this a new top-level command, e.g. swift build-destinations or swift package-destinations? This would also naturally avoid the "experimental" naming since it could just not be installed for now.

@MaxDesiatov
Copy link
Contributor Author

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 swift package seemed to be the most adjacent.

Thanks for the suggestion, I'll move it to the top level.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Nov 28, 2022

swift build-destinations or swift package-destinations?

@neonichu WDYT of swift destination? I also think it should be singular in the name, all other commands we have use singular form for nouns. For comparison, in Rust it looks like rustup target, so maybe we could keep this new command's name short and memorable if doesn't need experimental- prefix for now?

@tomerd also interested in your opinion on this.

@tomerd
Copy link
Contributor

tomerd commented Nov 28, 2022

consistency is good. we should run this by the community as part of the pitch

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Nov 30, 2022

Thinking about it more, would it make more sense to install the new top-level tool after all, just keeping it named experimental-destination? I wonder if not installing would imply users have to build it on their own locally, which is a bit too high barrier for just trying it out.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Dec 6, 2022

Confirmed with @tomerd that he's fine with keeping this as a subcommand of swift package. The benefit of it is that we don't have to make installation changes in multiple places for a new top-level command, and that may not be worth the effort for an experimental command (for now).

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)
Copy link
Contributor

@neonichu neonichu Dec 7, 2022

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@MaxDesiatov MaxDesiatov Dec 15, 2022

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.

Copy link
Contributor

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.

Copy link
Contributor

@neonichu neonichu left a 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.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Dec 7, 2022

I still think it's wrong to break the meaning of swift package, even for an experimental use case

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.
@MaxDesiatov MaxDesiatov force-pushed the maxd/list-destinations branch from 13ec06e to 23e8991 Compare December 12, 2022 17:02
@MaxDesiatov
Copy link
Contributor Author

@swift-ci please smoke test

@MaxDesiatov MaxDesiatov requested a review from neonichu December 12, 2022 17:04
@MaxDesiatov
Copy link
Contributor Author

@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.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Dec 12, 2022

Also, I didn't add a CMakeLists.txt for the new targets. In my understanding, the new tool isn't needed in the initial stage of the bootstrap build, right?

@neonichu
Copy link
Contributor

Also, I didn't add a CMakeLists.txt for the new targets. In my understanding, the new tool isn't needed in the initial stage of the bootstrap build, right?

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.

@MaxDesiatov
Copy link
Contributor Author

MaxDesiatov commented Dec 15, 2022

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.

@MaxDesiatov MaxDesiatov merged commit d632f36 into main Dec 15, 2022
@MaxDesiatov MaxDesiatov deleted the maxd/list-destinations branch December 15, 2022 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants