Sự khác biệt giữa các thư mục của nhà cung cấp lib lib và nhà cung cấp khác là gì?

Về phân cấp thư mục nguồn, luôn có một số tính năng phổ biến, chẳng hạn như src, dochoặc testthư mục, có nội dung khá dễ hiểu.

Tuy nhiên, tôi nhận ra rằng các dự án lớn có cả a libvà vendorthư mục, trong khi tôi luôn nghĩ rằng chúng giống nhau, vì tên của chúng gợi ý bao gồm cả bên thứ ba librariestừ bên ngoài vendors. Mặc dù vậy, nhìn thấy cả hai trong cùng một dự án có nghĩa là một sự khác biệt.

Tôi không thể tìm thấy bất kỳ thông tin nào cũng như trên Google cũng như trên các nguồn như Tiêu chuẩn phân cấp hệ thống tập tin , mặc dù đây thực sự là một thông lệ phổ biến .

Dưới đây là một ví dụ chi tiết hơn với Symfony : một khi bạn tạo một dự án, bạn sẽ nhận được một libthư mục ở thư mục gốc của dự án. Trong thư mục này, cấu trúc sau được tìm thấy:

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

Ở đây, symfonythư mục chứa tất cả lõi của Symfony.

Khi tôi nhìn thấy một libhoặc librariesthư mục, tôi nghĩ về:

• Thư viện, không phải plugin, mô-đun, v.v.
• OOP thay vì thủ tục, nơi áp dụng (ví dụ PHP)

Khi tôi nhìn thấy một vendorthư mục, tôi nghĩ về:

• Thư viện, plugin, mô-đun, thành phần, v.v. Không chỉ thư viện, mà bất kỳ thứ gì được cung cấp bởi bên thứ ba.
• Và những thứ không phải là mã, như một bộ biểu tượng.

Khi tôi nhìn thấy libvà các vendorthư mục, tôi nghĩ về một vài điểm khác biệt:

1. libchỉ giữ thư viện, vendorcó thể chứa bất cứ thứ gì thực sự,
2. liblà nơi tôi nên đặt thư viện của mình, vendornơi tôi nên đặt bất cứ thứ gì của bên thứ ba (bao gồm cả mã của tác giả gốc),
3. liblà nơi các thư viện của tác giả gốc của dự án được đặt (nếu đó không phải là tôi), trong khi đó vendorlà nơi tác giả ban đầu đặt bất cứ thứ gì của bên thứ ba.
4. Bạn có thể giả định một cách an toàn rằng bất cứ điều gì trong libđược cấp phép theo cùng giấy phép với phần còn lại của dự án.

Bất kỳ một trong những điều trên áp dụng, là đủ lý do để có các thư mục khác nhau. AFAIK không có thực hành thường được chấp nhận. Một số cộng đồng có các thông lệ chung trong cộng đồng, nhưng đó chỉ là về nó.

Đối với ví dụ cụ thể về Symfony: Symfony là một khung công tác và tôi nghĩ điều mà các nhà phát triển đang cố gắng nói là trong ứng dụng Symfony, các thư viện cốt lõi của khung là mã nhà cung cấp, tức là đến từ bên thứ ba chứ không phải từ tác giả ban đầu của ứng dụng (bạn).

Tổng quát hóa câu trả lời của @ WayneM nhưng không dám chỉnh sửa nó quá nhiều.

Vì vậy, có vẻ như cấu trúc này có thể được quan sát trong các khung ứng dụng (ít nhất là Rails và Symfony).

Đó là một cách để giữ nguyên cấu trúc lib/ srccho các nhà phát triển ứng dụng, đồng thời thêm mức độ khoảng cách khác do sử dụng khung: vendorthư mục thực sự chứa các thư viện của khung, để lại libthư mục cho các thư viện đi kèm của ứng dụng và srccho nguồn của nó các tập tin.

Nó là một trò chơi xa hơn lib, rất quan trọng vì không có khung, ứng dụng này vô dụng, nhưng không bị nhà phát triển ứng dụng chạm vào: đó là thư viện của nhà cung cấp khung .

Trong trường hợp của một cái gì đó như Symfony, liblà mã ứng dụng (được viết bởi các nhà phát triển) và vendorlà mã của bên thứ ba. Hãy nghĩ về nó giống như lib là srcthư mục thông thường và nhà cung cấp là lib. Tôi thường thấy phong cách đó trong PHP vì bạn tách các mẫu html ra khỏi các lớp thực tế.

Từ hướng dẫn Đường ống tài sản Rails :

• app/assets dành cho các tài sản thuộc sở hữu của ứng dụng, chẳng hạn như hình ảnh tùy chỉnh, tệp JavaScript hoặc biểu định kiểu.

• lib/assets dành cho mã thư viện của riêng bạn không thực sự phù hợp với phạm vi của ứng dụng hoặc các thư viện được chia sẻ trên các ứng dụng.

• vendor/assets dành cho các tài sản thuộc sở hữu của các thực thể bên ngoài, chẳng hạn như mã cho các plugin JavaScript và khung CSS.

Tôi biết đây không phải là một câu hỏi dành riêng cho Rails, nhưng lời giải thích rất hay và rõ ràng và có lẽ mở rộng sang các khung / cấu trúc dự án khác.