Qual è la differenza tra le cartelle "lib" e "vendor"?

103

Per quanto riguarda la gerarchia di cartelle di origine, ci sono sempre alcune caratteristiche comuni, come la src, doco le testcartelle, che sono piuttosto facile da capire il contenuto.

Tuttavia, mi sono reso conto che i grandi progetti hanno sia a libche vendorcartelle, mentre avevo sempre pensato che fossero gli stessi, poiché i loro nomi suggeriscono di includere "terze parti librariesda esterni vendors". Anche se, vedendo sia nello stesso progetto significa che v'è una differenza.

Non sono riuscito a trovare alcuna informazione né su Google né su fonti come il Filesystem Hierarchy Standard , anche se questa è in realtà una pratica in qualche modo comune .

Ecco un esempio più dettagliato con Symfony : una volta creato un progetto, ottieni una libcartella alla radice del tuo progetto. In questa cartella si trova la seguente struttura:

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

Qui, la symfonycartella contiene tutto il core di Symfony.

directory-structure

— MattiSG
fonte

3

@YannisRizos So che non è nella loro fonte. Una volta che inizi a lavorare su un progetto e generi moduli, però, finirai con lib/vendoraltre directory vendor. E non sono i soli . "Tutti possono selezionare qualsiasi struttura dir" Sì, grazie. Tutti possono codificare come vogliono. Se voglio chiamare src"woudzigouga", posso. Non sto chiedendo se posso ma perché gli altri seri e famosi fanno qualcosa che sembra una buona pratica.

— MattiSG,

2

A parte l'ovvio, che libcontiene librerie di base (librerie assolutamente indispensabili o librerie costruite dallo stesso autore del framework) e vendorcon librerie di terze parti, non credo che ci sia un'altra distinzione sana. Tale distinzione è in qualche modo importante per una serie di ragioni e ha senso come pratica generica.

— yannis,

1

a proposito, potresti aggiungere i chiarimenti nei commenti alla domanda stessa?

— yannis,

@YannisRizos Quali chiarimenti? La ricerca del codice di Google che prova la mia domanda non è del tutto fasulla? Sarebbe davvero utile se tu potessi dettagliare la "varietà di motivi" per cui la distinzione è importante, oltre a spiegare come alcune terze parti incluse possano essere più essenziali di altre - se sono incluse, c'è una ragione, a meno che i manutentori sono incompetenti e il codice include in batch.

— MattiSG,

1

Puoi toccare le cose in / lib /, non puoi toccare le cose in / vendor /

— Timo Huovinen,

64

Quando vedo una directory libo libraries, penso a:

Librerie, non plugin, moduli, ecc.
OOP anziché procedurale, laddove applicabile (ad es. PHP)

Quando vedo una vendordirectory, penso a:

Librerie, plugin, moduli, componenti, ecc. Non solo librerie, ma tutto ciò che viene fornito da una terza parte.
E cose che non sono codice, come un set di icone.

Quando vedo libe vendordirectory, penso ad alcune distinzioni:

libcontiene solo librerie, vendorpuò contenere qualsiasi cosa,
libè dove dovrei mettere le mie librerie, vendordove dovrei mettere qualsiasi cosa di terze parti (incluso il codice dell'autore originale),
libè dove si trovano le biblioteche dell'autore originale del progetto (se non sono io), mentre vendorè dove l'autore originale ha messo qualcosa di terze parti.
Puoi tranquillamente supporre che tutto ciò che è in libè concesso in licenza con la stessa licenza del resto del progetto.

Qualunque sia una delle precedenti, è una ragione sufficiente per avere cartelle diverse. AFAIK non esiste una pratica generalmente accettata. Alcune comunità hanno pratiche comuni a livello di comunità, ma questo è tutto.

Per quanto riguarda l'esempio specifico di Symfony: Symfony è un framework e penso che gli sviluppatori stiano cercando di dire che in un'applicazione Symfony le librerie core del framework sono codici del fornitore, cioè provenienti da terze parti e non dall'autore originale dell'applicazione (voi).

— Yannis
fonte

2

“Roba che non è il codice” sarebbe in datao resources(o qualcosa di più preciso sulla falsariga di img), IMHO. Inoltre, nel nostro esempio di Symfony, in vendorrealtà contiene tutto il core di Symfony, quindi a meno che non ottenga la tua denominazione di "autore originale", non credo che si adatti ai tuoi punti 2 e 3.

— MattiSG

1

@MattiSG Ah, scusa, non sto dicendo che dovrebbe adattarsi a tutti e quattro i punti. Solo uno. E "Roba che non è codice" dovrebbe essere in una directory resourceso assets, ma a seconda del progetto potrebbe avere senso in una vendordirectory (preferisco assetsdavvero).

— yannis,

4

Cosa c'è di meglio singolare o plurale? libvs libse vendorvs vendors?

— Quang,

4

@Quang I progetti più popolari che ho visto usano singolarmente, ma non ho idea di quale sia il migliore.

— yannis,

@YannisRizos: cosa ti fa pensare alla OOP invece che alla procedura?

— Matt O'Brien,

21

Generalizzando la risposta di @ WayneM ma non osando modificarla così tanto.

Quindi, sembra che questa struttura possa essere osservata nei framework applicativi (almeno Rails e Symfony).

È un modo per mantenere intatta la struttura lib/ srcper gli sviluppatori di applicazioni, aggiungendo l'altro livello di distanza portato dall'uso di un framework: la vendorcartella contiene effettivamente le librerie del framework, lasciando la libcartella per le librerie incluse nell'applicazione e srcper la sua fonte File.

È un "più distante" lib, vitale poiché senza il framework, l'applicazione è inutile, ma non deve essere toccata dallo sviluppatore dell'applicazione: sono le librerie del fornitore del framework .

— MattiSG
fonte

10

Nel caso di qualcosa come Symfony, libè il codice dell'applicazione (cioè scritto dagli sviluppatori) ed vendorè un codice di terze parti. Pensa che la lib è ciò che srcè normalmente la cartella e il fornitore è lib. Normalmente vedo quello stile in PHP perché separi i modelli html dalle classi reali.

— Wayne Molina
fonte

2

Dalla guida della pipeline delle risorse Rails :

app/assets è per risorse di proprietà dell'applicazione, come immagini personalizzate, file JavaScript o fogli di stile.
lib/assets è per il codice delle tue librerie che non si adatta davvero all'ambito dell'applicazione o alle librerie condivise tra le applicazioni.
vendor/assets è per le risorse che appartengono a entità esterne, come il codice per plugin JavaScript e framework CSS.

So che questa non è una domanda specifica di Rails, ma la spiegazione è buona e chiara e probabilmente si estende ad altri framework / strutture di progetto.

— Chico Carvalho
fonte