Cocoapods: Podfile Konflikte durch zwei Pods mit dem gleichen Namen, aber unterschiedliche Quelle

Question

Ich habe meine eigenen privaten Spezifikationen Repository mit internen Pods. Ich habe den Pods Präfixe hinzugefügt, aber jetzt, wo ich zu Swift migriere, möchte ich sie loswerden.

Wenn ich jedoch die Präfixe los werde (z. B. JAMNetworking zu Netzwerk) und zwei Quellen in der Poddatei angeben, bekomme ich Konflikte, da Netzwerk ein vorhandener öffentlicher Pod aus dem Master-Repository ist. Ich weiß, dass eine mögliche Lösung darin besteht, die Git-Repository-URL neben jedem Pod anzugeben, aber es ist für mich ärgerlich, die URL für jeden Pod hinzuzufügen, so dass ich nach einer eleganten Lösung suche. Ich habe einige Ideen, aber keine schien zu funktionieren:

A) Fügen Sie der Quelle einen Namen hinzu und geben Sie den Quellennamen für jeden Pod an, z.

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

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

B) zwei Definitionen mit der Innenseite angegebenen Quelle erstellen:

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 

Leider nur diese eine der def als gültig annimmt und die andere ignorieren ... so ist es in diesem Fall würde das öffentliche installieren. Wenn ich nach der Installation wechsle, deinstalliere ich das öffentliche und installiere das interne.

C) Mehrere Ziele erstellen. Es wird ein Fehler über mehrere Ziele mit demselben Namen zurückgegeben.

Denken Sie, dass es möglich ist, eine elegante Lösung zu finden, ohne die URL für jeden Pod hinzuzufügen oder das Hinzufügen von Präfixen zu vermeiden?

Answer 1

Die elegante Lösung im Moment ist, Ihre Präfixe zu behalten. Betrachten

a) Es ist allgemein vereinbart, dass Best Practice ist für Ihre pod identisch mit seiner exponierten Swift Modul

b) Swift Module verknüpfen kann nicht mit einem duplizierten Namen

an ein anderes Modul genannt zu werden .. Das wirft die Frage auf, wie doppelte Podnamen verwaltet werden.

Erica Sadun came to the same conclusion here. Bis so etwas wie das Reverse-DNS-Kennung vorgeschlagen darin Stande kommt,

Paketnamen müssen klar und spezifisch sein, ja, aber sie sollten Begriffe vermeiden, weil überlappen sich, wenn Sie ein Paket namens SwiftString und jeder Bob Jane und Harry hat auch ein Paket namens SwiftString, Namenskollisionen sind unvermeidlich ...

Und bis dahin bevorzugen SadunSwiftString zu SwiftString und vermeiden Sie das Problem von Anfang an.

bleiben Sie mit den Präfixen, da das wirkliche Problem hier Swift's Namespacing über der Modulebene ist. Und nach der Zeit werden wir alle SPM verwenden, ohne Zweifel!