-
Notifications
You must be signed in to change notification settings - Fork 1.4k
improve output when resolving packages #3427
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
motivation: when resolving packages, the output is lacking key information about computing the appropriate package version. this can mislead users about what SwiftPM is doing and where the time is spent. changes: 1. expose willComputeVersion/didComputeVersion on WorkspaceDelegate 2. use willComputeVersion/didComputeVersion in SwiftTool::ToolWorkspaceDelegate to print information about the version computation stage 3. add duration information to WorkspaceDelegate::fetchingDidFinish and WorkspaceDelegate::repositoryDidUpdate 4. print duration infortmation SwiftTool::ToolWorkspaceDelegate about fetching and updating, in addition to computing 5. remove empty delegates since they are potentialy hiding dperecations 6. adjust test
Sources/Commands/SwiftTool.swift
Outdated
| return AbsolutePath(env, relativeTo: workingDir) | ||
| } | ||
|
|
||
| /// Returns the sandbox profile to be used when parsing manifest on macOS. |
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.
this is just dead code I removed, probably need separate 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.
| func didDownloadBinaryArtifacts() | ||
| } | ||
|
|
||
| public extension WorkspaceDelegate { |
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.
this is likely to impact users of libSwiftPM, but I think worth doing o that the delegates dont run into runtime issues when we deprecate APIs
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.
Agreed, this is worth resolving in the client. Once we adopt semantic versioning this will also stop becoming an issue.
|
old output new output (updated) |
|
@swift-ci please smoke test |
| /// Called when the resolver begins to be compute the version for the repository. | ||
| func willComputeVersion(package: PackageIdentity, location: String) | ||
| /// Called when the resolver finished computing the version for the repository. | ||
| func didComputeVersion(package: PackageIdentity, location: String, version: String, duration: DispatchTimeInterval) |
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.
Adding this callback is particularly great — is it guaranteed that the package is "done" at this point, i.e. checked out to the right version and there is no chance that PubGrub might go back and check out a different version?
Also, I think that the "version" at this point could be anything, right? A branch name, etc? I wonder if we should have a more generic name for the parameter.
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.
Adding this callback is particularly great — is it guaranteed that the package is "done" at this point, i.e. checked out to the right version and there is no chance that PubGrub might go back and check out a different version?
afaict it is
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.
Also, I think that the "version" at this point could be anything, right? A branch name, etc? I wonder if we should have a more generic name for the parameter.
I believe this is actually only used for actual semantic versions, using branches will trigger a different flow where this will not be called afaict.
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.
see #3427 (comment)
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 see. It makes sense, since these are all resolved messages that are being added. I think it's fairly useful, at least in a UI, to see what branches individual packages get checked out to — that would be an argument for keeping the output from the checkout callbacks.
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.
Maybe "evaluate"?
Evaluating version for https://github.com/apple/swift-argument-parser.git
Evaluated https://github.com/apple/swift-argument-parser.git to 0.3.2 (0.04s)
"Compute" is fine though Computed ... at ... doesn't sound right. 🤔
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 wondering if "checking out" wouldn't still be a better term for the actual git checkout at the end, since that does match the semantics of the Git operation.
part of the idea here is to decouple this from git terminology as with SE-0292 some of these will not be git operations at all
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 wondering if "checking out" wouldn't still be a better term for the actual git checkout at the end, since that does match the semantics of the Git operation.
part of the idea here is to decouple this from git terminology as with SE-0292 some of these will not be git operations at all
That's a good point. In that sense, does it make sense to combine "creating working copy" and "resolved" to just "creating working copy for at " since in the case of SE-0292 there won't be a separate copying vs checking out step.
I guess I didn't realize until just now that the "working copy resolved" is the matching "did" part of the "creating working copy" message.
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 guess I didn't realize until just now that the "working copy resolved" is the matching "did" part of the "creating working copy" message.
its actually not :) they are two distinct actions: creating the working copy, then pointing it to the computed version. In the suggested output above, we are printing on "willCreateWorkingCopy" and "didCheckout". printing before creating the working directory is important because sometime its slow so we need to give the user an indication of what is happening. printing when checkout is complete is to let the user know which revision (version, branch) we landed on eventually and is actually not super useful other than when using branch dependencies.
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 see. Either way I think that it would be good to start each line with a verb, for consistency. But it's a minor point.
|
@swift-ci please smoke test |
fb8868f to
d438a67
Compare
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
abertelrud
left a comment
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.
LGTM. Thanks for taking this on!
|
@swift-ci please smoke test |
motivation: when resolving packages, the output is lacking key information about computing the appropriate package version. this can mislead users about what SwiftPM is doing and where the time is spent. changes: 1. expose willComputeVersion/didComputeVersion on WorkspaceDelegate 2. use willComputeVersion/didComputeVersion in SwiftTool::ToolWorkspaceDelegate to print information about the version computation stage 3. add duration information to WorkspaceDelegate::fetchingDidFinish and WorkspaceDelegate::repositoryDidUpdate 4. print duration infortmation SwiftTool::ToolWorkspaceDelegate about fetching and updating, in addition to computing 5. remove empty delegates since they are potentialy hiding dperecations 6. adjust test
motivation: when resolving packages, the output is lacking key information about computing the appropriate package version. this can mislead users about what SwiftPM is doing and where the time is spent.
changes: