Skip to content

refactor workspace repository handling #3766

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

Conversation

tomerd
Copy link
Contributor

@tomerd tomerd commented Sep 29, 2021

motivation: make supporting registry depedencies easier

changes:

  • rename LocalPackageContainer to FileSystemPackageContainer and move it to workspace module as internal struct
  • rename RepositoryPackageContainer to SourceControlPackageContainer and move it to the workspace module as internal class
  • remove RepositoryPackageContainerProvider and move its logic to workspace itself, including the logic to switch over dependecy type (local/remote) and providing the correct container type
  • conform workspace to PackageContainerProvider and change getContiner call-sites to use it
  • reorgnize repository related methods in a consistent manner so its easier to read the code that deals with repositories
  • adjust call sites and tests

rdar://81621441

@tomerd
Copy link
Contributor Author

tomerd commented Sep 29, 2021

@mattt this addresses some of your questions and takes some of your ideas from #3640, in effort to make it simpler (I hope!) to add registry support. lmk what you think (2nd commit, the first is #3698 which I plan to merge once CI is green)

@tomerd
Copy link
Contributor Author

tomerd commented Sep 29, 2021

needs #3698 first

@tomerd tomerd force-pushed the refactor/workspace-package-container-provider branch 2 times, most recently from 1dc9c22 to 7859936 Compare September 29, 2021 07:03
motivation: make supporting registry depedencies easier

changes:
* rename LocalPackageContainer to FileSystemPackageContainer and move it to workspace module as internal struct
* rename RepositoryPackageContainer to SourceControlPackageContainer and move it to the workspace module as internal class
* remove RepositoryPackageContainerProvider and move its logic to workspace itself, including the logic to switch over dependecy type (local/remote) and providing the correct container type
* conform workspace to PackageContainerProvider and change getContiner call-sites to use it
* reorgnize repository related methods in a consistent manner so its easier to read the code that deals with repositories
* adjust call sites and tests

rdar://81621441
@tomerd tomerd force-pushed the refactor/workspace-package-container-provider branch from 7859936 to 6a99db8 Compare September 29, 2021 07:32
@tomerd
Copy link
Contributor Author

tomerd commented Sep 29, 2021

@swift-ci please smoke test


extension Workspace {
extension Workspace: PackageContainerProvider {
public func getContainer(
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 the key change, it replaces RepositoryPackageContainerProvider which was removed

case .localSourceControl, .remoteSourceControl:
return try self.checkoutRepository(package: package, at: checkoutState)
case .registry:
fatalError("registry dependencies are supported at this point")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mattt this is where you can plug the registry "fetch" operation. we may want to do something about CheckoutState since its very source control centric. open to ideas

case .localSourceControl, .remoteSourceControl:
try self.removeRepository(dependency: dependencyToRemove)
case .registry:
fatalError("registry dependencies are supported at this point")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mattt this is where you would plug the registry remove handler, if one is needed (for cleanup)

}

private extension Workspace.ManagedArtifact {
fileprivate extension Workspace.ManagedArtifact {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

the diff above is a mess, but nothing material has changed, just moved methods around to better organize the code in this huge file

@mattt
Copy link
Contributor

mattt commented Sep 29, 2021

@tomerd Thanks so much for your helpful comments to guide my implementation 😄. I'll rebase #3640 against this and let you know when I'm finished.

@tomerd
Copy link
Contributor Author

tomerd commented Sep 29, 2021

@swift-ci please smoke test

case .root, .fileSystem:
fatalError("local dependencies are supported")
case .localSourceControl, .remoteSourceControl:
try self.removeRepository(dependency: dependencyToRemove)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these two cases be routed to the same method? It seems to me that the current implementation of removeRepository(dependency:) handles only remote source control dependencies, but not local repositories.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch 🙇

@tomerd tomerd force-pushed the refactor/workspace-package-container-provider branch from 1713cb1 to 904cf8d Compare September 29, 2021 22:30
@tomerd
Copy link
Contributor Author

tomerd commented Sep 29, 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 Sep 30, 2021
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

@tomerd tomerd merged commit e26d07b into swiftlang:main Sep 30, 2021
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