Cocoapods: подфайл конфликтует из-за наличия двух подов с одинаковым именем, но с разным источником.

У меня есть собственный репозиторий спецификаций с внутренними модулями. Раньше я добавлял префиксы к модулям, однако теперь, когда я перехожу на Swift, я хотел бы избавиться от них.

Однако, если я избавлюсь от префиксов (например, JAMNetworking to Networking) и укажу два источника в подфайле, у меня возникнут конфликты, поскольку сеть — это существующий общедоступный модуль из главного репозитория. Я знаю, что одним из возможных решений является указание URL-адреса репозитория git рядом с каждым модулем, но меня раздражает добавлять URL-адрес для каждого модуля, поэтому я ищу элегантное решение. У меня есть несколько идей, но ни одна из них не сработала:

A) Добавьте имя к источнику и укажите имя источника для каждого модуля, например

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

К сожалению, это принимает только одно из определений как действительное и игнорирует другое... поэтому в этом случае будет установлено общедоступное. Если я переключаюсь после установки, то удаляю общедоступную и устанавливаю внутреннюю.

C) Создайте несколько целей. Он возвращает ошибку о нескольких целях с одним и тем же именем.

Как вы думаете, возможно ли найти элегантное решение, не добавляя URL-адрес для каждого модуля или избегая добавления префиксов?


person jomafer    schedule 30.06.2016    source источник


Ответы (1)


Элегантным решением на данный момент является сохранение ваших префиксов. Рассмотреть возможность

а) Принято считать, что наилучшей практикой является то, что имя вашего модуля идентично его открытому модулю Swift.

б) Модули Swift не могут ссылаться на другой модуль с повторяющимся именем.

... что делает спорным вопрос о том, как управлять повторяющимися именами модулей.

Эрика Садун пришла к такому же выводу. До тех пор, пока не произойдет что-то вроде предложенного там обратного DNS-идентификатора,

Имена пакетов должны быть четкими и конкретными, да, но они должны избегать терминов, которые будут перекрываться, потому что, когда у вас есть пакет с именем SwiftString и у каждого Боба, Джейн и Гарри также есть пакет с именем SwiftString, конфликты имен неизбежны...

А до тех пор предпочитайте SadunSwiftString SwiftString и избегайте этой проблемы с самого начала.

придерживайтесь префиксов, так как реальная проблема здесь заключается в отсутствии Swift пространства имен над уровнем модуля. И к тому времени, когда это будет решено, мы все, без сомнения, будем использовать SPM!

person Alex Curylo    schedule 06.07.2016