0

我有自己的带有内部 pod 的私有规范存储库。我曾经为 pod 添加前缀，但现在我正在迁移到 Swift，我想摆脱它们。

但是，如果我去掉前缀（例如 JAMNetworking 到 Networking）并在 Podfile 中指定两个源，我会遇到冲突，因为 Networking 是来自主存储库的现有公共 pod。我知道一种可能的解决方案是在每个 pod 旁边指定 git 存储库 url，但是为每个 pod 添加 url 对我来说很烦人，所以我正在寻找一个优雅的解决方案。我有一些想法，但似乎都没有奏效：

A)为源添加名称并指定每个 pod 的源名称，例如

source 'master', 'https://github.com/CocoaPods/Specs.git'
source 'internal', 'https://myurl.git'

pod 'samePodName', 'master'
pod 'samePodName', 'internal'

B）使用内部指定的源创建两个定义：

def publicPods
    source 'master', 'https://github.com/CocoaPods/Specs.git'
    pod 'samePodName'
end

def internalPods
    source 'internal', 'https://myurl.git'
    pod 'samePodName'
end

target 'MyProject' do
    publicPods
    internalPods
end

不幸的是，这只需要一个 def 为有效而忽略另一个......所以在这种情况下它将安装公共的。如果我在安装后切换，则卸载公共的并安装内部的。

C)创建多个目标。它返回有关具有相同名称的多个目标的错误。

您认为不添加每个 pod 的 url 或避免添加前缀就可以找到一个优雅的解决方案吗？

4

1 回答 1

2

目前优雅的解决方案是保留您的前缀。考虑

a) 人们普遍认为，最佳实践是让您的 pod 与其暴露的 Swift 模块命名相同

b) Swift 模块不能链接到另一个具有重复名称的模块

...这使得如何管理重复的 pod 名称的问题变得毫无意义。

Erica Sadun在这里得出了同样的结论。直到其中提出的反向 DNS 标识符之类的东西通过，

包名需要明确和具体，是的，但它们应该避免重叠的术语，因为当你有一个名为 SwiftString 的包并且每个 Bob、Jane 和 Harry 也有一个名为 SwiftString 的包时，名称冲突是不可避免的......

并且，在那之前，更喜欢 SadunSwiftString 而不是 SwiftString，并从一开始就避免这个问题。

坚持使用前缀，因为这里真正的问题是 Swift 在模块级别之上缺乏命名空间。到那个问题解决的时候，我们都将使用 SPM，毫无疑问！

于 2016-07-06T22:54:47.457 回答