-
Notifications
You must be signed in to change notification settings - Fork 1.4k
refactor location abstractions #3764
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
c17e07d
to
d5cd15c
Compare
motivation: reduce dependency on string location information, in support of registry based dependencies changes: * add location information to PackageReference::Kind, using AbsolutePath and URL where appropriate * seperate out sourceControl dependencies to local and remote, where remote carries AbsolutePath and rmeote carries URL * add Location to RepositorySpecifier with local and remote, where remote carries AbsolutePath and rmeote carries URL * expand IdentityResolver to resolve identity from PackageReference::Kind, AbsolutePath and URL * adjust call sites (tons!) * adjust tests and test utilities (tons!) rdar://82954076
d5cd15c
to
51fe9f9
Compare
public enum Location: Equatable, Encodable { | ||
case local(AbsolutePath) | ||
case remote(Foundation.URL) | ||
} |
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 new enum is another key change
case localSourceControl(AbsolutePath) | ||
|
||
/// A remote source package. | ||
case remoteSourceControl(Foundation.URL) |
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 enum change is the key change
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.
What's the difference between fileSystem
and localSourceControl
? Do we do anything to ensure remoteSourceControl
is indeed remote (e.g., what if URL scheme is file://
?), or it doesn't matter?
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 there an opportunity for us to reuse the SourceControl.Location
enumeration here?
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.
yes, my plan is to further consolidate / cleanup after this initial but big PR lands.
return url.absoluteString | ||
} | ||
} | ||
} |
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 new enum is another key change
9943305
to
de989b6
Compare
@abertelrud @neonichu @elsh @yim-lee this PR includes refactoring we discussed several times with regards to how location is managed, and that is required to land SE-0292. its actually a pretty small change in the model itself but it has huge impact on call sites, especially in tests. given the large number of the lines changed, please focus on the core model changes which are highlighted in comments note that this and #3698 are key PRs to help land SE-0292 |
@swift-ci please smoke test |
@swift-ci please smoke test |
if package.kind != .remote { | ||
return queue.async { | ||
let container = LocalPackageContainer( | ||
if let repositorySpecifier = package.repositorySpecifier { |
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.
@mattt here you would need to add a case for the registry, and probably we can rename RepositoryPackageContainerProvider to something more generic that deals with all PackageContainer types, perhaps rename to DefaultPackageContainerProvider
productFilter: .everything | ||
) | ||
} else { | ||
throw StringError("invalid location: \(location)") |
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.
with the new model, we can do things here much more safely
/// | ||
/// This could be a remote repository, local repository or local package. | ||
public let location: String | ||
// FIXME: we should not need this | ||
//@available(*, deprecated) |
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.
after landing this PR, there will be follow up to clean up call sites that still depend on location string. there are very few now, mostly for display so we are getting there
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.
Great, this will do a lot to clarify the meaning of the code.
/// The URL of the repository. | ||
public let url: String | ||
// FIXME: transition url to location |
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 for follow up PR
@@ -550,9 +550,19 @@ extension RepositoryManager.RepositoryHandle { | |||
guard let status = Status(rawValue: repository.status) else { | |||
throw StringError("unknown status :\(repository.status)") | |||
} | |||
// FIXME: encode the type |
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 for follow up PR, its not too bad
} | ||
|
||
/// Creates a package identity from a URL. | ||
/// - Parameter url: The package's URL. |
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.
/// - Parameter url: The package's URL. | |
/// - Parameter urlString: The package's URL. |
case localSourceControl(AbsolutePath) | ||
|
||
/// A remote source package. | ||
case remoteSourceControl(Foundation.URL) |
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.
What's the difference between fileSystem
and localSourceControl
? Do we do anything to ensure remoteSourceControl
is indeed remote (e.g., what if URL scheme is file://
?), or it doesn't matter?
this is exactly one of the goals of this PR, |
@swift-ci please smoke test |
@swift-ci please test package compatibility |
self = .sourceControl(identity: settings.identity, location: settings.location, requirement: settings.requirement) | ||
switch settings.location { | ||
case .local(let path): | ||
self = .sourceControl(identity: settings.identity, location: path.pathString, requirement: settings.requirement) |
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.
Should we do a follow-on to separate out the described location similarly?
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.
yes we could, less critical at this point imo
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.
Yes, absolutely less critical.
case .root(let _path), .fileSystem(let _path): | ||
path = _path | ||
default: | ||
throw InternalError("invalid package type \(package.kind)") |
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.
Could we add the package identity to the message here (or is it perhaps already part of the metadata?). That would make it much easier to try to figure out errors coming in from the field that have this 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.
sure. this is an internal error so a programmer error and not user one, so less important IMO
case .root, .fileSystem: | ||
break | ||
default: | ||
throw InternalError("invalid package type \(package.kind)") |
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.
Same comment as the other message. If it's already part of the context for whatever handler wraps this call, so it will show up as metadata for a diagnostic, then that's even better.
|
||
public enum Location: Equatable { | ||
case local(AbsolutePath) | ||
case remote(Foundation.URL) |
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.
In the past I think we had some issues with Foundation representing git@...
URLs, at least on Darwin. I agree that using URL instead of String here makes more sense conceptually, but do we think there might be side effects? We should of course report them if there, but this might be something to watch for.
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 PR helps remove the logic that depends on checking if there is a scheme or not, and instead uses the type: localSourceControl
vs remoteSourceControl
, so ideally this should no longer be an issue regardless
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. Yes, if SwiftPM is no longer asking those same questions but mainly using the URL as a container of URL-formatted strings, then that might go better.
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.
yes this is the goal - make the concrete location opaque to logic, so it only gets used when we pass it to git, where we use absoluteString to write out the full value
is there a specific use case you recall that we need to add a test for to make sure this works correctly in that sense?
motivation: reduce dependency on string location information, in support of registry based dependencies
changes:
rdar://82954076