CODEWITHSUNDEEP
ioscocoapodspodspecpodfile
jomafer
jomafer

Reputation: 2725

Cocoapods: Podfile conflicts by having two pods with the same name but different source

I have my own private specs repository with internal pods. I used to add prefixes to the pods, however now I'm migrating to Swift I'd like to get rid of them.

However if I get rid of the prefixes (e.g. JAMNetworking to Networking) and I specify two sources in the Podfile, I'm getting conflicts as Networking is a existing public pod from the master repository. I know one possible solution is to specify the git repository url next to each pod, but it's annoying for me to add the url for each pod so I'm searching for an elegant solution. I have some ideas, but none of them seemed to work:

A) Add a name to the source and specify the source name for each pod, e.g.

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

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

B) create two definitions with the source specified inside:

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

Unfortunately this only takes one of the def as valid and ignore the other one...so in this case it would install the public one. If I switch after installing then uninstall the public one and installs the internal one.

C) Create multiple targets. It's returning an error about multiple targets with the same name.

Do you think it's possible to find an elegant solution without adding the url for each pod or avoiding adding prefixes?

Upvotes: 0

Views: 3720

Answers (1)

Alex Curylo
Alex Curylo

Reputation: 4772

The elegant solution at the moment is to retain your prefixes. Consider

a) It's commonly agreed that best practice is for your pod to be named identically to its exposed Swift module

b) Swift modules may not link to another module with a duplicated name

... which renders moot the question of how to manage duplicate pod names.

Erica Sadun came to the same conclusion here. Until something like the reverse-DNS identifier proposed therein comes to pass,

Package names need to be clear and specific, yes, but they should avoid terms that will overlap because when you have a package called SwiftString and every Bob, Jane, and Harry also has a package called SwiftString, name collisions are inevitable...

And, until then, prefer SadunSwiftString to SwiftString and avoid the issue from the start.

stick with the prefixes since the real problem here is Swift's lack of namespacing above the module level. And by the time that's resolved we'll all be using SPM, no doubt!

Upvotes: 2

Related Questions