[RFC] Declare SPM dependencies in podspec

[mfazekas]

Background

Swift Package Manager is becoming the de-facto standard for new libraries, due to its builtin support in Xcode. Currently Cocoapods libraries that want's to consume a SPM package have these choices:

• convert their lib to SPM and migrate off CocoaPods
• write a pod spec for the dependency
• ask users to install the SPM manually [?]

Suggested solution

Introduce SPM dependencies as part of pod spec.

In ruby this could look like:

  s.spm_dependency(
    url: 'https://github.com/CocoaLumberjack/CocoaLumberjack.git',
    requirement: {kind: 'upToNextMajorVersion', minimumVersion: '3.8.0'},
    targets: ['CocoaLumberjack']
  )

This would perform the following modifications: 1.) Add the declared Swift Package Manger dependency to the Pods project 2.) Add the CocoaLumberjack dependency to the pod's target

Prototype

Proof of concept implementation is available at: https://github.com/mfazekas/pods-spm-dep-poc/

Questions/to be addressed:

1. The POC uses SPM syntax for versions {kind: 'upToNextMajorVersion', minimumVersion: '3.8.0'}, but it think we'd be better of using the gem version constraints syntax. ~> 3.8.0. But we'll need a method that converts gem version constraints to SPM. Also not everything is representable. Like Version Range require upper and lover range.

   gem version	spm
   ~>2.1.0	{kind: "upToNextMinor",minimumVersion: "2.1.0" }
   ~>2.1	{kind:"upToNextMajor",minimumVersion:"2.1"}]
   >=1.0.0,<1.2.0	{kind"versionRange",minimumVersion:"1.0.0",maximumVersion:"1.2.0"}
   =1.0.3	{kind:"exact",version:"1.0.3"}

2. Lockfile. I don't think we can/should put SPM to the lock file. If we want to put SPM to the lock file we'd need to resolve the version. But that is something Xcode does. Xcode stores resolved data in .xcworkspace/xcshareddata/swiftpm/Package.resolved which is checked into the GIT. I'd say we're better not duplicating that info.

Notes:

• We don't support SPM dependencies in Podfile, just in pod spec, those can be added to the user's project in Xcode.
• Stale SPM dependencies can be handled by removing all non required SPM packages from the Pods project
• Multiple pod might depend on the same SPM package, in such case we'd need to merge requirements and handle potential conflicts.
• For some reason for Swift I also needs also to adjust SWIFT_INCLUDE_PATHS, so that Targets in Pod projects can find the modules. (Otherwise I get No such module error)

References/related issues:

10049

11618

10463

https://developer.apple.com/documentation/packagedescription/package/dependency/requirement-swift.enum https://www.swift.org/package-manager/ https://guides.cocoapods.org/syntax/podspec.html https://forums.swift.org/t/possible-to-use-spm-packages-from-cocoapods-pods-project/53187/14

[Westacular]

I think it's becoming increasingly important for CocoaPods to address this need.

My initial understanding (which could be mistaken) is that for Swift Macros, the only way to define and distribute them that works with Xcode is via SPM. And as you said, a variety of projects (notably the official Apple swift-* utility ones, like swift-algorithms and swift-collections) are SPM only.

[dnkoutso]

Yes, I echo that sentiment for Swift macro support.

[orta]

We chatted (pretty briefly) about this idea and have a general consensus that we should support it in CocoaPods. Right now there are (at least) three implementations of the idea:

• Yours (key source file)
• @segiddins' plugin (key source file)
• @igor-makarov's gem (key source file)

I think everyone is all working in the same sort of space here, but I think you've got the right abstraction level for getting started. I think we should look at the simplest implementation ATM, which is adding it at Podspec level as dependencies.

We are open to a PR adding this to CocoaPods core 👍🏻

---

1. While I think that CocoaPods/Bundle style semantic version declarations are easier to read, I think having something which can be directly passed to SPM is probably the winner here - its about us being forwards compatible with the SPM package format, if someone uses a ref which doesn't work in a newer SPM then they can update the Podspec and aren't forced to update CocoaPods.

2. I think we could note the dependency exists in our lockfile, but I think the resolving and locking process should all live in SPM (which means leaving their Package.resolved as the real source of truth) - this is a bit lossy, but feels like the right starting place given that SPM is an evolving platform (vs CocoaPods which ideally wants to not have to handle SPM changes)

---

For me the question mark is whether duplicate code being in the app is going to be an issue, if a dependency you use includes the pod "CocoaLumberJack" and another includes the SPM version of it then the person running pod install is at a bit of a bind.

Perhaps there could be some sort of de-duplication or ahead of time warnings (CP knows the repo for both for example), but maybe that's a 2.0 version of this feature.

[mfazekas]

Added a prs: https://github.com/CocoaPods/Core/pull/743 and https://github.com/CocoaPods/CocoaPods/pull/11953

[yaochenfeng]

+1

[zhu-xiaowei]

+1

[Mioke]

With the release of Xcode 15, the Swift macro feature is officially available. We now want to incorporate this feature into the development repository of CocoaPods to assist in development. Therefore, may I inquire about the current progress and plans regarding this issue?

[snooky23]

Hi Team, what is the plan for supporting SPM? Is there an ETA? :)

[trinhngocthuyen]

Hi Team, what is the plan for supporting SPM? Is there an ETA? :)

@snooky23 while waiting for the support from CocoaPods, you might want to look for a plugin that supports SPM integration. I wrote cocoapods-spm plugin to simplify such an integration. Hope it helps!

[bensonarafat]

Any plan on this guys?

[Mioke]

Can take a look at this stackoverflow discussion for temporary solution.

[matej-podzemny]

+1

[AlexMoumou]

+1