Pods, Carthage e SPM: o dilema do gerenciamento de pacotes da Swift

Noah Trupin Blocked Unblock Seguir Seguindo 10 de janeiro

Em 2019, o Swift evoluiu de um dos poucos projetos de código aberto da Apple para uma linguagem completa que serviu como a potência por trás do desenvolvimento dos sistemas da Apple, e até se espalhou para outros sistemas operacionais como o Linux. Agora, na versão 4.2, no horizonte a muito aguardada versão do Swift 5, o Swift se tornou muito popular por sua orientação de protocolo e base na capacidade de escrever aplicativos nativos para múltiplas plataformas.

O Swift 3 foi uma versão marcante para todos os usuários e desenvolvedores do Swift: foi um lançamento de quebra de código, alterando a maioria de sua sintaxe, removendo aspectos da linguagem e adicionando outros, e introduzindo outras ferramentas e aprimoramentos importantes como o Swift Package Manager e Swift Bibliotecas principais para Linux. Com o Swift 3 surgiu, no entanto, outra decisão difícil para os desenvolvedores. O Swift Package Manager, o terceiro gerenciador de pacotes para desenvolvedores Swift, mas o primeiro oficial, estava em jogo, diversificando ainda mais o processo de seleção e distribuição de bibliotecas e frameworks.

Dilema do gerenciamento de pacotes da Swift

O dicionário do Google define um dilema como “uma situação na qual uma escolha difícil precisa ser feita entre duas ou mais alternativas, especialmente as igualmente indesejáveis”. Agora, eu não diria que todos os gerentes de pacotes disponíveis são indesejáveis, mas posso concordar que nenhum deles é perfeito. Como qualquer software faz, os gerentes de pacotes têm seus triunfos e suas deficiências, embora as deficiências de cada um possam levar a um aborrecimento quando são usados no desenvolvimento. Os três gerenciadores de pacotes principais do Swift são o Cocoapods, o Carthage e o Swift Package Manager (SPM).

Cocoapods é o mais velho do grupo, estando presente desde os tempos em que o Objective-C era a principal linguagem de desenvolvimento de software da Apple. Lançado pela primeira vez em 17 de setembro de 2011, o Cocoapods originalmente fornecia bibliotecas e frameworks para aqueles que usavam a linguagem C-orientada a objetos, abrindo caminho para os gerenciadores de pacotes que o seguiram. Quando o Swift se tornou mainstream, Cocoapods expandiu-se graciosamente para abranger bibliotecas e frameworks para a nova linguagem, a linguagem na qual os outros gerenciadores de pacotes seriam construídos posteriormente. Quando novembro de 2014 chegou, o próximo gerenciador de pacotes foi lançado, o que significa que Cocoapods não era mais o único distribuidor para aqueles que usavam o Xcode. A capacidade de ter várias opções, todas fortes, fez com que o gerenciador de pacotes Swift original ficasse sob um polêmico; Embora muitos o considerem revolucionário para os desenvolvedores Swift e Objective-C, outros o bombardeiam por suas aparentes falhas.

  • Uma das características mais notáveis do Cocoapod foi a sua automação completa do processo de dependência, onde os desenvolvedores só precisavam executar a pod install e Cocoapods buscar e construir as dependências, inseri-los no projeto, vinculá-los a ele e gerar um espaço de trabalho para abranger ambos o projeto e os pods. Acontece que, embora o recurso fosse uma grande conveniência, os desenvolvedores não estavam totalmente satisfeitos com ele: embora o processo tenha poupado tempo e esforço significativos, ele também assumiu o controle do projeto, colocando-o nas mãos dos Cocoapods. e deixar seus processos manipular arquivos e configurações do projeto. Foi uma dor silenciosa que os desenvolvedores sentiram, uma que não foi dublada até o lançamento do próximo gerenciador de pacotes. Com o passar do tempo, os desenvolvedores ficaram menos satisfeitos em permitir que o popular terceiro assumisse as rédeas da criação de pacotes para seus projetos.
  • Enquanto os gerenciadores de pacotes mais novos são escritos no Swift, para o Swift, o Cocoapods é escrito em Ruby, o que significa que os desenvolvedores precisam ter familiaridade no idioma para operar o gerenciador de pacotes. Muitas pessoas conhecem Ruby e a curva de aprendizado não é íngreme, portanto, a inconveniência de adicionar arquivos de outro idioma não é muito trabalhosa; no entanto, o fato de que o gerenciador de pacotes do Swift não foi escrito em sua própria linguagem, como Nuget , PyPi ou NPM , e que outra linguagem teve que ser usada é uma dor para os desenvolvedores.
  • Cocoapods é centralizado, algo comum em gerenciadores de pacotes (um indicador comum é o registro de pacotes). A centralização em um gerenciador de pacotes significa que existe um registro de código central no qual os pacotes são hospedados e podem ser visualizados, e onde o cliente, geralmente uma interface de linha de comando, pode extrair o código para gerar o pacote. Todos os Pods hospedados em sua rede podem ser acessados no site cocoapods.org , algo que é útil para desenvolvedores que não têm um pacote específico em mente ou apenas querem procurar o que está disponível. No entanto, muitos parecem estar se desviando para o novo conceito de descentralização, o que significa que o Cocoapods está se tornando menos o sistema ideal de gerenciamento de pacotes.

Embora Cocoapods tenha suas falhas e tenha sido alvo de desprezo ultimamente, ainda é o mais antigo dos gerenciadores de pacotes da Swift, e é incrivelmente amigável para iniciantes devido à sua automação.

CocoaPods.org
O Dependency Manager para projetos iOS e Mac cocoapods.org

Carthage é o segundo gerenciador de pacotes a chegar ao grupo, e suas principais diferenças em Cocoapods são evidentes desde o início. Lançado em 18 de novembro de 2014, estava disponível apenas dois meses após o lançamento oficial do Swift 1.1 e suportou ambos os objetivos-C no Swift. Carthage pegou o que era um tópico azedo para desenvolvedores em Cocoapods: enquanto Cocoapods foi escrito em Ruby, Carthage atende a seus usuários com um gerenciador de pacotes escrito inteiramente em Swift. Junto estava o poder do gerenciamento de dependências na linguagem que a Apple apóia e que seu projeto está escrito, Carthage se orgulha de aproveitar o sistema de compilação do Xcode, enquanto dá ao desenvolvedor liberdade na integração de suas dependências. Com o Carthage, o desenvolvedor recebe o controle sobre as dependências de seu projeto, permitindo que, depois que o Carthage as construa, vincule e gerencie-as como quiserem.

  • O README de Carthage é incrivelmente descritivo e útil ao aprender como integrar o Carthage em seu projeto pela primeira vez (e posteriormente, para necessidades mais complexas), mas para um desenvolvedor com menos experiência pode ser bastante complicado começar a usar. Com um processo de integração mais longo, no entanto, mais simplicidade e controle a longo prazo. Uma vez que o Carthage está configurado e as dependências estão vinculadas, basta adicionar uma linha a um arquivo incrivelmente simples (em vez de uma linha ou mais a um arquivo Ruby) e um único comando, carthage update , para gerar seus novos frameworks, onde novos os podem ser importados da mesma forma que os originais. O Carthage elimina o incômodo de lidar com vários arquivos .xcproject dentro de um maior .xcworkspace e remove a volumosa estrutura de arquivos adicionada ao seu projeto principal, ao invés disso apenas complementa o projeto com pastas .framework na raiz do seu projeto que claramente indicam o nome do arquivo. o quadro.
  • Carthage oferece um grau de controle que não é visto em outros gerenciadores de pacotes, de Swift, Objective-C ou outros idiomas, e isso é um controle completo. Embora pareça desafiador primeiro criar os scripts de execução e vincular as estruturas ao projeto, o processo se torna incrivelmente suave quando acostumado. Com a adição manual ao projeto e à vinculação, o desenvolvedor recebe o controle sobre exatamente o que acontece com suas dependências quando o Carthage as constrói. Se o desenvolvedor decidir que não deseja uma estrutura no projeto, eles não precisam editar o Cartfile e atualizar todas as dependências; eles podem apenas remover a estrutura do projeto Xcode e remover o comando de vinculação do script de execução.
  • A descentralização tem aumentado ultimamente, sendo 2018 um ano imenso quando se trata de software adotando seus princípios. Com Carthage criado em 2014, pode-se dizer que foi um dos primeiros a adotar o mundo do software, embora a descentralização em computadores tenha sido popular por algum tempo, especialmente em criptomoedas. O Carthage é um gerenciador de pacotes descentralizado, o que significa que não há servidor núcleo nem lista central de projetos. Em vez disso, o gerenciador de pacotes chega a vários repositórios do GitHub para buscar o código a ser construído em frameworks. Embora isso complique a localização de estruturas compatíveis com o Carthage, significa que Carthage é mais seguro e aproveita um conceito que os desenvolvedores estão começando a amar. Além disso, significa que Carthage pode ser mais lento que Cocoapodes enquanto procura e constrói dependências, mas é a escolha do desenvolvedor se os trade-offs valerem a pena.

Carthage é revolucionário em como ele executa o gerenciamento de pacotes, e aqueles que podem ser complexos no início, ele serve como um gerenciador de pacotes proeminente, permitindo que os desenvolvedores assumam o controle de suas dependências.

Cartago / Cartago
Um gerenciador de dependências simples e descentralizado para Cocoa – Carthage / Carthage github.com

O Swift Package Manager é o mais novo a entrar nas fileiras dos gerenciadores de pacotes Swift, sendo lançado em 13 de setembro de 2016 com o lançamento do Swift 3. O Swift Package Manager lembra mais seus equivalentes em outros idiomas do que o outro gerenciador de pacotes do Swift. É mais fácil pegar quem vem de outro idioma. Ele adiciona uma estrutura de arquivos ao seu projeto que faria com que alguém vindo do Cargo ou do NPM se sentisse em casa, organizando cada dependência em sua própria pasta representando o módulo. É igualmente simples configurar para desenvolvimento para iOS, Mac e Linux, um privilégio que os outros gerenciadores de pacotes parecem não ter. O manifesto do gerente também se assemelha ao de outras linguagens, com uma estrutura específica semelhante a JSON.

  • O Swift Package Manager é novo, embutido na linguagem Swift (não é necessário instalar nada!) E sempre atualizado para as versões mais recentes do Swift e do Xcode, assim que são lançadas. Como ele foi desenvolvido com o Swift 3 originalmente e é atualizado com frequência, ele evita os problemas do código legado e a necessidade de atualizar com a mesma frequência, algo que outros gerenciadores de pacotes precisam fazer. A interface de linha de comando integra-se diretamente ao Xcode e ao processo de criação do Swift, o que significa que não há nenhuma configuração adicional para fazer fora do arquivo Package.swift para declarar dependências.
  • O Swift Package Manager tem uma assinatura importante que Cocoapods e Carthage não possuem: o selo da Apple que é o gerenciador de pacotes oficial do Swift. Desenvolvido a céu aberto na Apple com contribuições da comunidade, ele compartilha o aspecto do código aberto que é popular entre os desenvolvedores e é usado pelos outros gerenciadores de pacotes do Swift. O apoio da Apple e sua equipe trabalhando com o desenvolvimento principal dá ao Gerenciador de Pacotes do Swift um impulso de eficiência e credibilidade, o que significa que os desenvolvedores têm seus processos de construção acelerados e simplificados, sabendo que estão criando dependências usando o melhor software de gerenciamento de pacotes disponível no Mac ou Linux para a linguagem Swift. Embora alguns desenvolvedores não sejam grandes fãs da Apple e de suas políticas e metodologias, é difícil negar que o Swift Package Manager é uma ótima criação deles.
  • Todas as linguagens de programação notáveis, e muitas das quais os desenvolvedores provavelmente nunca ouviram falar, têm seus próprios gerenciadores de pacotes para permitir a distribuição de estruturas e bibliotecas de terceiros para a comunidade de desenvolvimento. Cocoapods é diferente de outros gerenciadores de pacotes para o uso de outra linguagem e manipulação total do projeto, e o Carthage é diferente pelo seu controle dado ao desenvolvedor e à descentralização. A formação do Swift Package Manager é semelhante às suas contrapartes em outros idiomas, o que significa que um desenvolvedor que já lidou com dependências se sentirá confortável com ele. Os comandos na CLI são semelhantes aos de outros gerenciadores de pacotes, e o arquivo Package.swift é muito semelhante ao Manifest.json do Kotlin ou ao Package.json do JavaScript, e a estrutura que os arquivos executam no projeto ao qual estão sendo adicionados é quase idêntica à estrutura que eles adotam em outros idiomas.

O Swift Package Manager é considerado o futuro do gerenciamento de dependências em projetos Swift, e sua eficiência e simplicidade estão indo bem para preparar o caminho para essa previsão.

Swift.org
Swift é uma linguagem de programação de propósito geral construída usando uma abordagem moderna de segurança, desempenho e software… swift.org

Três gerenciadores de pacotes proficientes em um idioma podem ser um fardo para os desenvolvedores, estejam eles escolhendo o caminho certo ou desenvolvendo pacotes para serem usados em outros projetos, distribuídos pelo gerenciador. O dilema da Swift não inclui apenas a diversidade no gerenciamento de dependências, mas que cada gerenciador de pacotes está longe de ser perfeito e pode deixar muito a desejar. Os usuários do Cocoapod desejam que ele não tenha sido escrito em Ruby e que ele não tenha manipulado tanto o projeto, mas os usuários do Carthage desejavam que o processo não fosse tão complexo ou lento às vezes, e os usuários do Swift Package Manager desejaram que não fosse tão obscura ou cortada e seca com os gerenciadores de pacotes de outras linguagens. Do lado positivo, o sistema de gerenciamento de pacotes do Swift, embora esteja longe de ser perfeito, permite que os desenvolvedores tenham uma escolha, algo que não é tão fácil ou não está disponível em todos os outros idiomas.

Posfácio

Então, qual é o dilema do gerenciamento de pacotes da Swift? É que o Swift tem vários gerenciadores de pacotes, cada um com seus triunfos e falhas, e que há muitos fatores a serem considerados na escolha de uma ou etapas adicionais necessárias para o desenvolvimento de bibliotecas e estruturas para uso por outras pessoas. Embora possa ser um dilema, os gerenciadores de pacotes múltiplos da Swift contêm aspectos diferentes de suas contrapartes em outras linguagens, tornando o processo de criação e implementação de dependências no Swift único e poderoso à sua própria maneira.