Skip to content

Conversation

@tomerd
Copy link
Contributor

@tomerd tomerd commented Apr 23, 2021

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:
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
return AbsolutePath(env, relativeTo: workingDir)
}

/// Returns the sandbox profile to be used when parsing manifest on macOS.
Copy link
Contributor Author

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

Copy link
Contributor Author

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 {
Copy link
Contributor Author

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

Copy link
Contributor

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.

@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

old output

❯ rm -rf .build && swift package update
Fetching https://github.com/apple/swift-atomics.git from cache
Fetching https://github.com/apple/swift-numerics.git from cache
Fetching https://github.com/apple/swift-nio.git from cache
Cloning https://github.com/apple/swift-atomics.git
Resolving https://github.com/apple/swift-atomics.git at 0.0.3
Cloning https://github.com/apple/swift-nio.git
Resolving https://github.com/apple/swift-nio.git at 2.27.0
Cloning https://github.com/apple/swift-numerics.git
Resolving https://github.com/apple/swift-numerics.git at 0.1.0

new output (updated)

❯ rm -rf .build && ~/code/swift/swift-package-manager/.build/debug/swift-package update
Fetching https://github.com/apple/swift-atomics.git from cache
Fetching https://github.com/apple/swift-numerics.git from cache
Fetching https://github.com/apple/swift-nio.git from cache
Fetched https://github.com/apple/swift-numerics.git (1.10s)
Fetched https://github.com/apple/swift-atomics.git (1.10s)
Fetched https://github.com/apple/swift-nio.git (1.15s)
Computing version for https://github.com/apple/swift-atomics.git
Computed https://github.com/apple/swift-atomics.git at 0.0.3 (0.03s)
Computing version for https://github.com/apple/swift-numerics.git
Computed https://github.com/apple/swift-numerics.git at 0.1.0 (0.03s)
Computing version for https://github.com/apple/swift-nio.git
Computed https://github.com/apple/swift-nio.git at 2.27.0 (0.04s)
Creating working copy for https://github.com/apple/swift-numerics.git
Working copy of https://github.com/apple/swift-numerics.git resolved at 0.1.0
Creating working copy for https://github.com/apple/swift-nio.git
Working copy of https://github.com/apple/swift-nio.git resolved at 2.27.0
Creating working copy for https://github.com/apple/swift-atomics.git
Working copy of https://github.com/apple/swift-atomics.git resolved at 0.0.3

@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

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

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

@tomerd tomerd Apr 23, 2021

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

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.

Copy link
Contributor

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

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

Copy link
Contributor

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.

Copy link
Contributor Author

@tomerd tomerd Apr 23, 2021

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.

Copy link
Contributor

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.

@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

@swift-ci please smoke test

@tomerd tomerd added the ready Author believes the PR is ready to be merged & any feedback has been addressed label Apr 23, 2021
@tomerd tomerd force-pushed the feature/resolver-delegate-2 branch from fb8868f to d438a67 Compare April 23, 2021 01:15
@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

@swift-ci please smoke test

@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

@swift-ci please smoke test

Copy link
Contributor

@abertelrud abertelrud left a 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!

@tomerd
Copy link
Contributor Author

tomerd commented Apr 23, 2021

@swift-ci please smoke test

@tomerd tomerd self-assigned this Apr 23, 2021
@tomerd tomerd merged commit fc36e07 into swiftlang:main Apr 27, 2021
tomerd added a commit to tomerd/swift-package-manager that referenced this pull request Apr 27, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready Author believes the PR is ready to be merged & any feedback has been addressed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants