Por que preferir um gerenciador de pacotes a uma pasta da biblioteca?

Quando penso nos prós e contras de uma pasta estática da biblioteca e de um gerenciador de pacotes, sinto que a pasta da biblioteca é uma abordagem melhor.

Prós que vejo em uma pasta da biblioteca:

1. Não há necessidade de uma ferramenta externa para gerenciar pacotes.
2. Não requer conexão com internet para construir.
3. Construção mais rápida (sem verificação de pacotes).
4. Ambiente mais simples (menos conhecimento necessário).

Prós que vejo com um gerenciador de pacotes:

1. Ajuda com árvores de dependência complexas (e que podem ser gerenciadas baixando uma dependência junto com todas as suas dependências).
2. Ajuda a verificar se há uma nova versão disponível.

Parece que o setor decidiu seguir o caminho do gerenciador de pacotes para quase tudo o que é construído atualmente. Então, o que estou perdendo?

Um ponto importante ausente nas outras respostas:

Usar um gerenciador de pacotes significa ter uma configuração que indica quais versões da biblioteca você está usando e garante que as informações de configuração estejam realmente corretas.

Saber quais bibliotecas você usa e qual versão é muito importante se:

• precisa atualizar uma biblioteca devido a uma falha crítica de bug / segurança;
• ou apenas precisa verificar se uma falha de segurança anunciada afeta você.

Além disso, quando você realmente atualiza, o gerenciador de pacotes (geralmente) garante que todas as dependências transitivas sejam atualizadas conforme necessário.

Considerando que, com uma libpasta, você só tem um monte de arquivos (possivelmente binários e possivelmente modificados) e precisará adivinhar de onde eles vieram e qual versão eles são (ou confiar em alguns README, que podem ou não estar corretos )

Para abordar seus outros pontos:

Não há necessidade de ferramenta externa para gerenciar pacotes.

É verdade, mas a) como desenvolvedor de software, você precisa instalar cargas de ferramentas de qualquer maneira; portanto, mais uma não importa, eb) geralmente existem apenas um ou alguns gerenciadores de pacotes em qualquer campo (Maven / Gradle for Java, npm para JS / TypeScript, etc), por isso não é necessário instalar dezenas deles.

Não requer conexão com internet para construir.

Todos os gerenciadores de pacotes que conheço trabalham off-line, depois de baixar as dependências necessárias (o que pode acontecer logo após o download do próprio projeto).

Construção mais rápida (sem verificação de pacotes).

Provavelmente é verdade, mas parece improvável que a verificação do pacote offline leve uma quantidade significativa de tempo (é só comparar alguns números de versão). Uma verificação online pode demorar um pouco, mas pode ser desativada, se desejado (se estiver ativada por padrão - o Maven, por exemplo, nunca verifica atualizações de versões).

Ambientes mais simples (menos conhecimento necessário).

Verdade, mas como explicado acima, uma libpasta também requer conhecimento. Além disso, como explicado acima, você provavelmente trabalhará apenas com alguns gerenciadores de pacotes diferentes, que você já conhece.

Os profissionais da pasta lib desaparecem rapidamente depois que você passa do desenvolvimento em pequena escala para um trabalho maior.

Por exemplo, o "benefício" de não exigir uma ferramenta externa é superado pelo trabalho necessário para gerenciar manualmente suas dependências; portanto, a ferramenta será você (em mais de um sentido do mundo).

Você não precisa de uma conexão com a internet para gerenciar um pacote. Você pode usar repositórios locais.

Uma construção mais rápida pode ser verdadeira, mas dificilmente é algo que deve determinar se você deve usar um gerenciador de pacotes ou não. Afinal, não estamos falando de magnitudes de diferença, e isso também depende da sua configuração. Você pode facilmente criar uma compilação lenta usando um gerenciador de pacotes, mas isso é basicamente sabotagem.

Ambientes mais simples (menos conhecimento necessário)? Mais uma vez, no desenvolvimento em pequena escala, definitivamente, uma possibilidade. Você pode manter o projeto em sua cabeça completamente, até cada uma das poucas bibliotecas que estão sendo usadas. Adicione um script simples de makefile / outro e você terá um pacote completo.

Mas isso não torna os ambientes mais simples, apenas funciona em ambientes simples. No desenvolvimento em larga escala, você ficará feliz por usar ferramentas padrão em vez de soluções personalizadas. Afinal, você só precisa aprender uma vez (e quando o gerenciador de pacotes do dia é substituído pelo novo e interessante, você também precisa aprender).

Você está perdendo muitas das vantagens dos gerenciadores de pacotes.

1. Os gerenciadores de pacotes permitem evitar a verificação de binários grandes (vários megabytes ou maiores) no controle de origem. Fazer isso é um anátema para muitas ferramentas de controle de origem, sendo o git generalizado um deles. Tivemos um repositório atingido os limites de tamanho do Bit Bucket alguns meses atrás porque os desenvolvedores estavam verificando os CocoaPods. Outro projeto já estava no meio do caminho quando migramos do SVN porque estávamos fazendo o check-in de todos os nossos binários de lib (e não estávamos usando o NuGet). Como os gerentes de pacotes baixam pacotes rapidamente para cada desenvolvedor, eles eliminam a necessidade de verificar esses binários.
2. Eles impedem a mistura de arquivos / bibliotecas incompatíveis. As pastas podem conter versões mistas dos arquivos da biblioteca se alguém não a limpar adequadamente durante uma atualização. Eu vi um caso em que metade dos binários na pasta foram atualizados, resultando em erros muito estranhos. (Ele nem travou!) Levamos literalmente meses (não horas de trabalho, apenas tempo total) para descobrir o problema. Ao deixar o gerenciador de pacotes controlar a pasta inteira, você não pode obter versões mistas; você garante consistência. Eles também tornam muito mais difícil o uso de dependências incompatíveis , atualizando tudo automaticamente, instalando versões diferentes quando necessário ou apenas lançando avisos ou erros ao tentar usar versões incompatíveis de bibliotecas.
3. Eles estabelecem uma convenção compartilhada para gerenciar bibliotecas. Quando novos desenvolvedores entram em seu projeto, equipe, empresa etc., é provável que conheçam as convenções do gerente de pacotes. Isso significa que eles não precisam perder tempo descobrindo os detalhes de como as bibliotecas são gerenciadas em sua base de código.
4. Eles oferecem uma maneira padrão de versionar e distribuir suas próprias dependências e arquivos que não pertencem ao seu repositório. Eu os utilizei pessoalmente para alguns grandes arquivos de dados estáticos exigidos pelo meu aplicativo, para que funcione bem na versão de versões além do código binário.
5. Alguns gerenciadores de pacotes fornecem recursos adicionais durante a instalação. O NuGet adicionará dependências e arquivos de conteúdo ao seu arquivo csproj e pode até adicionar elementos de configuração ao arquivo de configuração.
6. Os arquivos da lista de pacotes documentam as versões de suas bibliotecas em um único local centralizado. Não preciso clicar com o botão direito do mouse em uma DLL e olhar o número da versão para descobrir qual versão da biblioteca estou usando. No Python, o autor da biblioteca pode nem ter incluído o número da versão nos arquivos py, portanto, talvez eu nem consiga diferenciar a versão da biblioteca a partir deles.
7. Eles desencorajam a instalação de dependências em toda a máquina. Os gerenciadores de pacotes fornecem uma maneira convencional de instalar dependências sem um instalador global . Quando suas opções são pasta lib e instalação global, muitos desenvolvedores de bibliotecas optam por oferecer suas bibliotecas primárias como instalações globais, em vez de binários para download que você precisa configurar por conta própria. (O histórico da MS demonstra isso. Também é o caso de muitas bibliotecas no Linux.) Isso realmente torna o gerenciamento de vários projetos mais difícil, pois você pode ter projetos com versões conflitantes e alguns desenvolvedores certamente escolherão a instalação global aparentemente mais simples do que ter sua própria biblioteca dir.
8. Eles tendem a centralizar a hospedagem e a distribuição. Você não precisa mais depender do site da biblioteca aleatória. Se eles falirem, o site de um gerenciador de pacotes bem-sucedido ainda terá todas as versões já carregadas. Os desenvolvedores também não precisam procurar muitos sites apenas para baixar novas bibliotecas; eles têm um local para procurar primeiro e até procurar opções diferentes. Também é mais fácil espelhar pacotes organizados de maneira padrão do que hospedar manualmente cópias de tudo, de sites ad-hoc.

Você também está exagerando o valor dos seus "benefícios".

1. Não há necessidade de ferramenta externa para gerenciar pacotes.

   "Externo" para quê? Verifico o executável do NuGet nos meus repositórios. É o único binário em que me sinto bem ao fazer o check-in, já que é pequeno e significa que não preciso fazer check-in de outros binários.

   O pip não apresenta problemas nessa frente, já que agora está empacotado com o Python e as alterações incompatíveis e reversas são extremamente raras. Você não vai desenvolver código Python sem ter o Python instalado externamente no seu projeto, de qualquer maneira.

   Quando alcançam ampla adoção, os gerentes de pacotes tendem a ser muito estáveis. Você não pode fugir sem algum tipo de ferramenta instalada globalmente para a maioria dos projetos, e um único gerenciador de pacotes é um requisito bastante leve. Geralmente, não é muito mais complicado do que ter o tempo de execução do idioma instalado.

2. Não requer conexão com internet para construir.

   Não consigo me conectar ao meu banco de dados sem uma conexão de rede. Se o banco de dados estiver hospedado na Amazon, preciso de uma conexão completa com a Internet. Preciso de uma conexão com a Internet para enviar e receber alterações através do controle de origem; um servidor de compilação também não pode fazer check-out do código para compilar sem algum tipo de conexão de rede. Você não pode enviar ou receber email sem um. Você não pode baixar bibliotecas para colocá-las na sua pasta lib sem uma! O desenvolvimento permanente sem uma conexão à Internet é praticamente inédito. Em alguns casos raros em que é necessário, você pode lidar com isso baixando os pacotes para um local que o gerenciador de pacotes possa consumir. (Eu sei que o NuGet e o pip estão felizes em extrair de uma simples pasta ou unidade de rede; suspeito que a maioria dos outros também possa.)

3. Construção mais rápida (sem verificação de pacotes).

   30 segundos durante a compilação automatizada e 5 segundos durante as compilações de desenvolvedores locais são uma boa opção para os benefícios que descrevi acima. Esses são prazos triviais que geralmente nem valem a pena considerar em comparação com os problemas que os benefícios resolvem.

4. Ambientes mais simples (menos conhecimento necessário).

   Uma ferramenta para o gerenciamento de pacotes e nada para o gerenciamento de bibliotecas não é realmente uma comparação justa. Sem a ferramenta, você precisa aprender qualquer processo personalizado que o projeto esteja usandopara gerenciar suas bibliotecas. Isso significa que você nunca tem certeza se o seu conhecimento existente se aplica a qualquer novo projeto que abordar. Você terá que lidar com qualquer abordagem de miscigenação criada por alguém ou criar a sua. Pode ser um diretório que contém todas as bibliotecas ou pode ser algo muito mais estranho. Talvez, para evitar o check-in das bibliotecas, alguém as coloque em uma unidade de rede e o único indicador de versão seja o nome da pasta. Como é isso ou uma instalação global realmente melhor? Por comparação, um gerenciador de pacotes oferece uma convenção limpa que será aplicada à maioria dos projetos que você encontrar.

O tema comum é que eles fornecem consistência, documentação e recursos, não apenas nos projetos, mas também entre eles. Isso simplifica a vida de todos.

Tendo convertido recentemente nosso produto do uso de bibliotecas baixadas manualmente para o gerenciamento automático de pacotes com o Nuget, posso dizer que o uso de um gerenciador de pacotes traz enormes benefícios.

Nosso produto é implementado em 27 projetos C #, que são relativamente pequenos para os padrões atuais. Algumas de nossas dependências de terceiros têm dezenas de assembléias.

Antes do Nuget, se eu quisesse atualizar todas as nossas dependências para a versão mais recente, teria que:

1. Rastrear onde eu poderia obter todas as bibliotecas atualizadas
2. Faça o download e descompacte / instale
3. Adicione as novas versões ao controle de origem
4. Examine manualmente todas as referências em nossos projetos e atualize-as para apontar para as novas montagens

Com 27 projetos e dezenas de assemblies de dependência, esse processo era muito propenso a erros e poderia levar horas.

Agora que atualizamos o Nuget, tudo foi feito para mim com um único comando.

Não há necessidade de ferramenta externa para gerenciar pacotes

Isso é meio inútil, não é? Se eu usar um gerenciador de pacotes, não preciso ter uma pasta lib. Eu também não preciso gerenciar os pacotes sozinho.

Não requer conexão com internet para construir

Além de não ter hoje uma conexão com a Internet durante o desenvolvimento, é um tanto raro (talvez com exceção de estar em trânsito), um gerenciador de pacotes decente não deve exigir que você tenha a versão mais recente para compilar seu aplicativo. Pode reclamar, mas não há razão para não criar com a versão que já instalou

Construção mais rápida (sem verificação de pacotes)

Esse é um aumento de velocidade bastante marginal, mas você pode argumentar sobre isso.

Ambientes mais simples (menos conhecimento necessário)

Atualmente, a maioria dos gerenciadores de pacotes é tão simples que dificilmente vale a pena tentar contorná-los fazendo isso. Existem até clientes visuais, se você quiser. Na verdade, eles escondem grande parte da croft que está acontecendo.

Os gerenciadores de pacotes também permitem que você compartilhe esses pacotes entre diferentes projetos. Se cinco dos meus projetos usam a mesma versão do Boost, não há necessidade de duplicar isso para cada projeto. Isto é especialmente verdade para as complexas árvores de dependência das quais você fala.

Com uma pasta lib, você gerencia pacotes apenas para esse projeto, enquanto um gerenciador de pacotes permite fazer isso em todo o ambiente de desenvolvimento com uma única ferramenta.

É a diferença entre usar apenas as bibliotecas (diretório lib) e usá-las, mantendo as meta-informações (gerenciador de pacotes) . Essa metinformação diz respeito a números de versão, dependências (transitivas) entre bibliotecas e outras.

As discussões sobre DLL hell, compatibilidade de bibliotecas, sistema de módulos java, OSGi e outros devem ser pelo menos suficientes para convencer alguns de que vale a pena ter alguma forma de gerenciamento de dependências.

• A versão da biblioteca e os problemas de dependência podem ser uma perda de tempo.

Também há o benefício de um repositório compartilhado (local), portanto, vários projetos não precisam manter cópias de bibliotecas importadas. Se alguém tem um projeto com 20 submódulos, alguns desses módulos possuem 40 dependências ímpares.

• Mais estrutura
• Mais recorte de bibliotecas
• Nenhuma decisão humana ad-hoc sobre bibliotecas

Existem alguns casos em que uma pasta lib pode ser necessária, por exemplo, ao lidar com bibliotecas obsoletas (uma versão dela não é mais mantida / disponível), uma versão modificada localmente de uma biblioteca, ...

Mas, para todo o resto, é como o desenvolvedor assumindo o papel de gerenciador de pacotes:

• O desenvolvedor precisará fazer o download das bibliotecas (requer internet)
• O desenvolvedor precisará verificar manualmente se há versões mais recentes
• ...

E IMHO, é menos conhecimento necessário, porque você precisa aprender sobre o uso da ferramenta externa, mas menos sobre as bibliotecas (ou seja, dependências).

Há outro problema não coberto por outras perguntas: compartilhar deps.

Digamos que você tenha dois pacotes criando a mesma biblioteca. Na melhor das hipóteses, não haverá nenhum conflito, mas o mesmo espaço HDD / SSD será usado duas vezes. Na pior das hipóteses, haverá vários conflitos, como versões.

Se você usar o gerenciador de pacotes, ele instalará a biblioteca apenas uma vez (por versão) e já fornecerá o caminho para ela.

PS: é claro, você precisa de vínculo dinâmico (ou função semelhante no seu idioma) para obter esse profissional.

Um dos principais motivos pelos quais as bibliotecas compartilhadas foram consideradas um item de progresso nos sistemas Unix e Windows da década de 90 foi como eles poderiam diminuir o uso de RAM quando vários programas usando o mesmo conjunto de bibliotecas foram carregados. O espaço do código só precisa ser alocado ONCE por biblioteca e versão exatas dessa biblioteca , o único uso de memória por instância restante é para variáveis ​​estáticas.

Muitos sistemas operacionais implementam bibliotecas compartilhadas de uma maneira que depende de mecanismos como o unix mmap () api - o que implica que uma biblioteca não apenas precisará ter exatamente a mesma versão, mas, na verdade, o mesmo arquivo. É simplesmente impossível tirar o máximo proveito de um programa que envia seu próprio conjunto de bibliotecas.

Dado que a memória é muito mais barata e as versões de bibliotecas precisavam de mais diversidade do que nos anos 90, esse argumento não tem tanto peso atualmente.