Qual é a diferença entre as pastas “lib” e “vendor”?

94

Com relação à hierarquia de pastas de origem, há sempre alguns recursos comuns, como as pastas src , doc ou test , que têm um conteúdo bastante fácil de entender.

No entanto, percebi que os grandes projetos têm as pastas lib e vendor , embora eu sempre achasse que eram os mesmos, já que os nomes deles indicam a inclusão de " libraries de terceiros a partir de vendors externo " Porém, ver ambos no mesmo projeto significa que é uma diferença.

Não encontrei nenhuma informação nem no Google nem em fontes como o Padrão de hierarquia do sistema de arquivos , embora essa seja realmente uma prática comum. p>

Aqui está um exemplo mais detalhado com o Symfony : depois de criar um projeto, você obtém uma pasta lib no raiz do seu projeto. Nesta pasta, a seguinte estrutura é encontrada:

lib
+--filter
+--form
+--…
+--vendor
    +--simpletest
    +--symfony

Aqui, a pasta symfony contém todo o núcleo do Symfony.

    
por MattiSG 05.12.2011 / 10:19
fonte

4 respostas

21

Generalizando a resposta do @ WayneM, mas não ousando editá-lo tanto.

Então, parece que essa estrutura pode ser observada em frameworks de aplicações (pelo menos no Rails e no symfony).

É uma maneira de manter intacta a estrutura lib / src para desenvolvedores de aplicativos, enquanto adiciona o outro nível de distância trazido pelo uso de uma estrutura: a pasta vendor na verdade contém as bibliotecas da estrutura, deixando a pasta lib para as bibliotecas incluídas na aplicação e src para seus arquivos de origem.

É um "mais distante" lib , vital, pois sem o framework, o aplicativo é inútil, mas não deve ser tocado pelo desenvolvedor do aplicativo: são as bibliotecas do fornecedor do framework .

    
por 07.12.2011 / 13:06
fonte
59

Quando vejo um diretório lib ou libraries , penso em:

  • Bibliotecas, não plugins, módulos, etc.
  • OOP em vez de procedural, onde isso é aplicável (por exemplo, PHP)

Quando vejo um diretório vendor , penso em:

  • Bibliotecas, plugins, módulos, componentes, etc. Não apenas bibliotecas, mas tudo que é fornecido por terceiros.
  • E outras coisas que não são código, como um conjunto de ícones.

Quando vejo os diretórios lib e vendor , penso em algumas distinções:

  1. lib contém apenas bibliotecas, vendor pode conter qualquer coisa realmente,
  2. lib é onde eu deveria colocar minhas bibliotecas, vendor onde eu deveria colocar qualquer coisa de terceiros (incluindo código do autor original),
  3. lib é onde as bibliotecas do autor original do projeto estão localizadas (se não for eu), enquanto vendor é onde o autor original coloca qualquer coisa de terceiros.
  4. Você pode assumir com segurança que o que está em lib está licenciado sob a mesma licença do restante do projeto.

Qualquer uma das opções acima, é motivo suficiente para ter pastas diferentes. AFAIK não há prática geralmente aceita. Algumas comunidades têm práticas comuns em toda a comunidade, mas isso é tudo.

Quanto ao exemplo específico do Symfony: Symfony é um framework e acho que o que os desenvolvedores estão tentando dizer é que em uma aplicação Symfony as principais bibliotecas do framework são código de fornecedor, ou seja, vindo de um terceiro e não do autor original da aplicação (você).

    
por 05.12.2011 / 12:00
fonte
10

No caso de algo como o Symfony, lib é o código do aplicativo (por exemplo, escrito pelos desenvolvedores) e vendor é um código de terceiros. Pense nisso como lib é o que a pasta src normalmente é e o fornecedor é lib. Eu normalmente vejo esse estilo no PHP porque você separa os modelos html das classes reais.

    
por 05.12.2011 / 14:16
fonte
0

Do guia Pipeline de recursos do Rails :

  • app/assets é para recursos pertencentes ao aplicativo, como imagens personalizadas, arquivos JavaScript ou folhas de estilo.

  • lib/assets é para o código de suas próprias bibliotecas que não se encaixa realmente no escopo do aplicativo ou nas bibliotecas que são compartilhadas entre aplicativos.

  • vendor/assets é para ativos pertencentes a entidades externas, como código para plug-ins de JavaScript e estruturas CSS.

Eu sei que esta não é uma questão específica do Rails, mas a explicação é boa e clara e provavelmente se estende a outras estruturas de frameworks / projetos.

    
por 28.06.2018 / 13:33
fonte