Jaka jest różnica między folderami „lib” i „vendor”?

103

Jeśli chodzi o hierarchię folderu źródłowego, nie zawsze są pewne wspólne cechy, takie jak src, doclub testfoldery, które mają dość łatwy do zrozumienia treści.

Jednak zdałem sobie sprawę, że duże projekty mają zarówno libi vendorfoldery, a ja zawsze myślałem, że były takie same, jak ich nazwy wskazywać na tym „innych firm librariesz zewnętrznych vendors”. Chociaż, widząc zarówno w tym samym projekcie oznacza, że jest różnica.

Nie mogłem znaleźć żadnych informacji ani w Google, ani w źródłach takich jak Hierarchia Standardów Systemu Plików , mimo że w rzeczywistości jest to jakoś powszechna praktyka.

Oto bardziej szczegółowy przykład z Symfony : po utworzeniu projektu otrzymujesz libfolder w katalogu głównym projektu. W tym folderze znajduje się następująca struktura:

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

Tutaj symfonyfolder zawiera cały rdzeń Symfony.

directory-structure MattiSG
źródło
3
@YannisRizos Wiem, że nie ma ich w źródle. Gdy jednak zaczniesz pracować nad projektem i wygenerować moduły, skończysz z lib/vendorinnymi katalogami vendor. I nie są jedynymi . „Każdy może wybrać dowolną strukturę reż.” Tak, dziękuję. Każdy może kodować w dowolny sposób. Jeśli chcę nazywać src„woudzigouga”, mogę. Nie pytam, czy mogę, ale dlaczego inni poważni i znani robią coś, co wygląda na dobrą praktykę.
MattiSG,
2
Poza oczywistym, że libposiada biblioteki podstawowe (absolutnie niezbędne biblioteki LUB biblioteki zbudowane od tego samego autora co framework) i vendorbiblioteki zewnętrzne, nie sądzę, żeby było jakieś inne rozsądne rozróżnienie. To rozróżnienie jest nieco ważne z różnych powodów i ma sens jako ogólna praktyka.
yannis,
1
btw, czy możesz dodać wyjaśnienia w komentarzach do samego pytania?
yannis,
@YannisRizos Jakie wyjaśnienia? Wyszukiwarka Google Code dowodząca, że ​​moje pytanie nie jest całkowicie fałszywe? Przydałoby się wyszczególnienie „różnorodnych powodów”, dla których rozróżnienie jest ważne, a także wyjaśnienie, w jaki sposób niektóre uwzględnione strony trzecie mogą być bardziej istotne niż inne - jeśli są uwzględnione, istnieje powód, chyba że opiekunowie są niekompetentni i zawierają kod partii.
MattiSG,
1
Możesz dotykać rzeczy w / lib /, nie możesz dotykać rzeczy w / vendor /
Timo Huovinen

Odpowiedzi:

64

Kiedy widzę katalog liblub libraries, myślę o:

  • Biblioteki, a nie wtyczki, moduły itp.
  • OOP zamiast proceduralnych, tam gdzie ma to zastosowanie (np. PHP)

Kiedy widzę vendorkatalog, myślę o:

  • Biblioteki, wtyczki, moduły, komponenty itp. Nie tylko biblioteki, ale wszystko, co zapewnia firma zewnętrzna.
  • I rzeczy, które nie są kodem, jak zestaw ikon.

Kiedy widzę libi vendorkatalogi, myślę o kilku wyróżnieniach:

  1. libposiada tylko biblioteki, vendormoże pomieścić wszystko naprawdę,
  2. libtam, gdzie powinienem umieścić moje biblioteki, vendorgdzie powinienem umieścić wszystko, co jest stronem trzecim (w tym kod oryginalnego autora),
  3. libto gdzie znajdują się biblioteki oryginalnego autora projektu (jeśli to nie ja), podczas vendorgdy oryginalny autor umieszcza cokolwiek innego.
  4. Możesz bezpiecznie założyć, że wszystko, co jest, libjest licencjonowane na tej samej licencji, co reszta projektu.

Niezależnie od tego, który z powyższych warunków ma zastosowanie, jest to wystarczający powód do posiadania różnych folderów. AFAIK nie ma ogólnie przyjętej praktyki. Niektóre społeczności mają wspólne praktyki w całej społeczności, ale o to właśnie chodzi.

Jeśli chodzi o konkretny przykład Symfony: Symfony jest frameworkiem i myślę, że programiści próbują powiedzieć, że w aplikacji Symfony podstawowymi bibliotekami frameworka są kod dostawcy, tj. Pochodzący od strony trzeciej, a nie od oryginalnego autora aplikacji (ty).

Yannis
źródło
2
„Rzeczy, które nie są kodem” będą w datalub resources(lub w bardziej precyzyjny sposób img) IMHO. Co więcej, w naszym przykładzie Symfony vendorfaktycznie zawiera cały rdzeń Symfony, więc chyba, że ​​nie otrzymam nazwy „oryginalnego autora”, nie sądzę, żeby pasowało to do twoich punktów 2 i 3.
MattiSG z
1
@MattiSG Ach, przepraszam, nie mówię, że powinno pasować do wszystkich czterech punktów. Tylko jeden. I „Rzeczy, które nie są kodem” powinny znajdować się w katalogu resourceslub assets, ale w zależności od projektu może mieć sens w vendorkatalogu ( assetsnaprawdę wolę ).
yannis,
4
Co jest lepsze w liczbie pojedynczej lub mnogiej? libvs libsi vendorvs vendors?
Quang
4
@Quang Najpopularniejsze projekty widziałem w liczbie pojedynczej, ale nie mam pojęcia, który z nich jest lepszy.
yannis
@YannisRizos: co sprawia, że ​​myślisz o OOP zamiast proceduralnym?
Matt O'Brien
21

Uogólniając odpowiedź @ WayneM, ale nie odważając się na tak wiele edycji.

Wygląda więc na to, że tę strukturę można zaobserwować w ramach aplikacji (przynajmniej Rails i Symfony).

Jest to sposób na utrzymanie struktury lib/ srcnienaruszonej dla programistów aplikacji, przy jednoczesnym dodaniu innego poziomu odległości wynikającego z użycia frameworka: vendorfolder faktycznie zawiera biblioteki frameworka, pozostawiając libfolder dla bibliotek dołączonych do aplikacji i srcdla jej źródła akta.

Jest to „bardziej odległe” lib, istotne, ponieważ bez frameworka aplikacja jest bezużyteczna, ale twórca aplikacji nie może jej dotknąć: to biblioteki dostawcy frameworka .

MattiSG
źródło
10

W przypadku czegoś takiego jak Symfony, libjest kodem aplikacji (tj. Napisanym przez programistów) i vendorjest kodem strony trzeciej. Pomyśl o tym, jak lib jest tym, co srczwykle jest folderem, a dostawcą jest lib. Zwykle widzę ten styl w PHP, ponieważ oddzielasz szablony HTML od rzeczywistych klas.

Wayne Molina
źródło
2

Z przewodnika po rurociągach zasobów Rails :

  • app/assets dotyczy zasobów będących własnością aplikacji, takich jak niestandardowe obrazy, pliki JavaScript lub arkusze stylów.

  • lib/assets jest dla kodu twoich bibliotek, który tak naprawdę nie pasuje do zakresu aplikacji lub tych bibliotek, które są współużytkowane przez aplikacje.

  • vendor/assets dotyczy zasobów będących własnością podmiotów zewnętrznych, takich jak kod wtyczek JavaScript i frameworków CSS.

Wiem, że nie jest to pytanie specyficzne dla Railsów, ale wyjaśnienie jest dobre i jasne i prawdopodobnie dotyczy innych ram / struktur projektu.

Chico Carvalho
źródło