Moves Pods<->SPM interoperability up several notches
Summary
I'm working on a project with a large number of CocoaPods dependencies that I'm trying to migrate to SPM. One of the worst "offenders" in terms of depended-on libraries is RxSwift, which is readily available as a Swift Package. However, some intermediary dependencies are only available as Pods, and this is of course leading to linking issues in the project as a whole. This may manifest as missing implied modules (such as RxCocoaRuntime, that gets flattened into the static library SPM prefers), or as duplicated symbols.
But ultimately what happens is that both package resolution paths are taken independently: CocoaPods' (dependency) and SPM's (spm_dependency).
There should be a way to establish a mapping (sometimes the package name will even change due to naming conventions, like NSObject+Rx (Pod) => NSObject-Rx (SPM) (diff: the + and the -)) of allowed overrides and allow SPM to take over the resolution. I'm suggesting a mapping because it's automatically opt-in and enables arbitrary granularity, to avoid surprises. This would mainly manifest not pulling in the CocoaPod version of those and linking the SPM libraries/frameworks in the Pods.xcodeproj / *.xcconfig instead.
Motivation
Moves Pods<->SPM interoperability up several notches
Summary
I'm working on a project with a large number of CocoaPods dependencies that I'm trying to migrate to SPM. One of the worst "offenders" in terms of depended-on libraries is RxSwift, which is readily available as a Swift Package. However, some intermediary dependencies are only available as Pods, and this is of course leading to linking issues in the project as a whole. This may manifest as missing implied modules (such as RxCocoaRuntime, that gets flattened into the static library SPM prefers), or as duplicated symbols.
But ultimately what happens is that both package resolution paths are taken independently: CocoaPods' (
dependency) and SPM's (spm_dependency).There should be a way to establish a mapping (sometimes the package name will even change due to naming conventions, like
NSObject+Rx(Pod) =>NSObject-Rx(SPM) (diff: the+and the-)) of allowed overrides and allow SPM to take over the resolution. I'm suggesting a mapping because it's automatically opt-in and enables arbitrary granularity, to avoid surprises. This would mainly manifest not pulling in the CocoaPod version of those and linking the SPM libraries/frameworks in the Pods.xcodeproj / *.xcconfig instead.Do you agree that this is a feasible approach?