Implement dependency resolution through package registry #3640
Conversation
mattt
force-pushed
the
package-registry-implementation
branch
from
1cdff33 to
b8f0af0
Compare
| /// | ||
| /// This is the root class for bridging the manifest & SCM systems into the | ||
| /// interfaces used by the `DependencyResolver` algorithm. | ||
| public class RepositoryPackageContainerProvider: PackageContainerProvider { |
There was a problem hiding this comment.
@tomerd @abertelrud After digging into the implementation a bit more, I hit a fork in the road and was interested to hear your ideas for how best to proceed.
Currently, responsibility for creating package containers falls to RepositoryPackageContainerProvider, which conforms to the PackageContainerProvider protocol.
My first instinct was to either create a complement to RepositoryPackageContainerProvider for registry packages, or to update that class to handle both repository and registry packages. However, I noticed that RepositoryPackageContainerProvider doesn't do much beyond copying some state from a Workspace and implementing the getContainer method requirement.
So my thinking here (73aa9bf) was that we could remove a layer of indirection by making Workspace conform to PackageContainerProvider directly. This way, we can access all of the information we need directly, (like registry configuration, netrc credentials, etc.).
Do you think this is the right approach to take?
mattt
force-pushed
the
package-registry-implementation
branch
from
c2b471c to
c37e97d
Compare
mattt
force-pushed
the
package-registry-implementation
branch
2 times, most recently
from
bd3fefd to
aed0139
Compare
mattt
force-pushed
the
package-registry-implementation
branch
from
0189c48 to
a5ca10e
Compare
This comment has been minimized.
This comment has been minimized.
mattt
force-pushed
the
package-registry-implementation
branch
from
f559cb5 to
2d679da
Compare
mattt
force-pushed
the
package-registry-implementation
branch
from
b99d3bb to
2d76085
Compare
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
Add RegistryManagerTests
Add downloaded case to ManagedDependency.State Update WorkspaceConfiguration serialization format to V5
mattt
force-pushed
the
package-registry-implementation
branch
from
7ff0e54 to
35d9d9e
Compare
mattt
requested review from
abertelrud,
friedbunny,
neonichu and
tomerd
as code owners
|
@swift-ci Please smoke test |
|
Back to draft to rebase on latest of |
Continue swiftlang#3640 and polish up the registry client.
Continue swiftlang#3640 and polish up the registry client.
Continue #3640 and polish up the registry client.
This PR builds on top of #3635 to implement dependency resolution through a registry service.
Motivation:
Implement SE-0292.
Modifications:
PackageRegistrylibrary and test target containing theRegistryManagerclient implementation.RegistryPackageContainerclass toPackageGraphmoduleWorkspaceto provideRegistryPackageContainerif the package is declared with a registry identifier (Currently WIP with hardcoded registry URL)PubGrubDependencyResolverto support registry packagesResult:
With this change, Swift Package Manager will be able to resolve package dependencies through a configured registry service.