[Feature Request] .podspec SPM packages automatically installed

[Dunedubby]

Motivation

Looking at the upcoming official CocoaPods/SPM integration, it looks like they are preferring to allow SPM packages to be built solely from .podspec information, without being declared in the Podfile. I also think this makes sense. I have forked and made a draft change here: https://github.com/Dunedubby/cocoapods-spm. What do you think?

Summary

.podspec SPM packages should be resolved and installed without requiring inclusion in the Podfile.

[trinhngocthuyen]

@Dunedubby Thank you for the feedback!

Actually, I came across this before and eventually landed on the current approach. As follows are the reasons.

First, an SPM package is somehow similar to a pod. Therefore, a design principle for this plugin is to align with how CocoaPods treats a pod/podspec.

• With podspecs, specifically, the source of a dependency (ex. the package URL) must not be declared in the podspec. Rather its source, if exists, must be declared in Podfile. See: dsl.rb#L725-L731.

Second, specifying a package's source in a podspec implies some problems, especially source conflicts. For example, if 2 pods A and B depend on a package X. Then, the source of X in A.podspec and B.podspec must stay consistent. This is a bit difficult in reality given many podspecs a modular project could have. I believe this is the main reason why CocoaPods decided not to have source declaration in podspecs in the first place.

Third, what if the project does not have any SPM-related pod and wishes to use an SPM package. We don't have any podspec at all, right? By specifying the package X in Podfile, we have Pods-<App> implicitly depending on X. Then we can use this package in the main target.

The above reasons are why we stick to the current approach (ie. dependencies in podspecs, declarations in Podfile). Hope they help clear the doubts!

[Dunedubby]

I understand. Your reasoning makes sense. I wonder if there's a way to maintain modularity though - so that an app doesn't have to know anything about its dependencies' dependencies if it doesn't want to. In my opinion, that's one of the best parts of using Pods, but I can see how being intentional with the sources for dependencies is important too. I wonder if the most CocoaPods-like solution would be to query swiftpackageindex.com as a default...

As of now the fork allows for both .spm_pkg calls and .spm_dependency resolution. This avoids the case when there are no .podspecs.

Thanks! Ultimately, I wonder what the CocoaPods team will choose to follow for their official SPM integration.

[Dunedubby]

Here's the Swift Package Index list, if you think it's worth trying to integrate: https://raw.githubusercontent.com/SwiftPackageIndex/PackageList/main/packages.json

[trinhngocthuyen]

Unfortunately, the SPI is not sufficient enough to tackle the issue. Unlike CocoaPods's Specs repo, the SPI's Package List repo mainly serves the purpose of discoverability.

There are two main downsides to integrating SPI into the plugin:

• Packages under the same name can coexist, such as wvabrinskas/Logger and elegantchaos/Logger. This leads to name conflicts when using it as a source of truth.
• Packages can be easily taken down. If such a package is removed from the list, those who're using it will suffer.