Tại sao thích một trình quản lý gói hơn một thư mục thư viện?

Khi tôi nghĩ về những ưu và nhược điểm của thư mục tĩnh và trình quản lý gói, tôi cảm thấy thư mục thư viện là cách tiếp cận tốt hơn.

Ưu điểm tôi thấy với một thư mục thư viện:

1. Không cần một công cụ bên ngoài để quản lý các gói.
2. Không cần kết nối internet để xây dựng.
3. Xây dựng nhanh hơn (không kiểm tra gói).
4. Môi trường đơn giản hơn (ít kiến ​​thức cần thiết).

Ưu điểm tôi thấy với một người quản lý gói:

1. Giúp với các cây phụ thuộc phức tạp (và có thể được quản lý tải xuống một phụ thuộc cùng với tất cả các phụ thuộc của nó).
2. Giúp kiểm tra nếu có phiên bản mới.

Có vẻ như ngành công nghiệp đã quyết định đi theo con đường quản lý gói cho hầu hết mọi thứ được xây dựng ngày nay. Vì vậy, tôi đang thiếu gì?

Một điểm quan trọng bị thiếu trong các câu trả lời khác:

Sử dụng trình quản lý gói có nghĩa là có một cấu hình cho biết bạn đang sử dụng phiên bản thư viện nào và đảm bảo rằng thông tin cấu hình thực sự chính xác.

Biết thư viện nào bạn sử dụng và phiên bản nào là rất quan trọng nếu bạn:

• cần cập nhật thư viện do lỗi nghiêm trọng / lỗ hổng bảo mật;
• hoặc chỉ cần kiểm tra xem một lỗ hổng bảo mật được công bố có ảnh hưởng đến bạn hay không.

Ngoài ra, khi bạn thực sự cập nhật, trình quản lý gói (thường) đảm bảo mọi phụ thuộc bắc cầu được cập nhật theo yêu cầu.

Trong khi với một libthư mục, bạn chỉ có một loạt các tệp (có thể là nhị phân và có thể sửa đổi), và bạn sẽ phải đoán chúng đến từ đâu và chúng là phiên bản nào (hoặc tin tưởng một số README, có thể đúng hoặc không chính xác ).

Để giải quyết các điểm khác của bạn:

Không cần công cụ bên ngoài để quản lý các gói.

Đúng, nhưng a) với tư cách là nhà phát triển phần mềm, dù sao bạn cũng cần cài đặt vô số công cụ, do đó, một thứ nữa thường không quan trọng và b) thường chỉ có một hoặc một vài trình quản lý gói trong bất kỳ trường nào (Maven / Gradle cho Java, npm cho JS / TypeScript, v.v.), vì vậy không giống như bạn cần cài đặt hàng tá chúng.

Không cần kết nối internet để xây dựng.

Tất cả các trình quản lý gói mà tôi biết đều hoạt động ngoại tuyến, một khi họ đã tải xuống các phụ thuộc cần thiết (có thể xảy ra ngay sau khi tải xuống dự án).

Xây dựng nhanh hơn (không kiểm tra gói).

Có thể đúng, nhưng có vẻ như việc kiểm tra gói ngoại tuyến sẽ không mất nhiều thời gian (chỉ là so sánh một số số phiên bản). Việc kiểm tra trực tuyến có thể mất một chút thời gian, nhưng có thể tắt nó nếu muốn (nếu nó được bật theo mặc định - ví dụ Maven không bao giờ kiểm tra các bản cập nhật cho các phiên bản phát hành).

Môi trường đơn giản hơn (yêu cầu ít kiến ​​thức hơn).

Đúng, nhưng như đã giải thích ở trên, một libthư mục cũng đòi hỏi kiến ​​thức. Ngoài ra, như đã giải thích ở trên, có lẽ bạn sẽ chỉ làm việc với một số ít người quản lý gói khác nhau mà bạn đã biết.

Ưu điểm của thư mục lib biến mất nhanh chóng sau khi bạn chuyển từ phát triển quy mô nhỏ sang công việc lớn hơn.

Ví dụ, "lợi ích" của việc không yêu cầu một công cụ bên ngoài bị ảnh hưởng bởi công việc cần thiết để quản lý thủ công các phụ thuộc của bạn, vì vậy công cụ sẽ là bạn (theo nhiều nghĩa của thế giới).

Bạn không cần kết nối internet cho người quản lý gói. Bạn có thể sử dụng kho lưu trữ cục bộ.

Xây dựng nhanh hơn có thể đúng, nhưng hầu như không phải là thứ nên xác định có nên sử dụng trình quản lý gói hay không. Rốt cuộc, chúng ta không nói về tầm quan trọng của sự khác biệt và điều này cũng phụ thuộc vào cấu hình của bạn. Bạn có thể dễ dàng tạo một bản dựng chậm bằng trình quản lý gói, nhưng về cơ bản là phá hoại.

Môi trường đơn giản hơn (cần ít kiến ​​thức hơn)? Một lần nữa, trong phát triển quy mô nhỏ chắc chắn là một khả năng. Bạn có thể giữ dự án hoàn toàn trong đầu, xuống từng thư viện đang được sử dụng. Thêm một tệp tạo tệp đơn giản / tập lệnh xây dựng khác và bạn đã có cho mình một gói hoàn chỉnh.

Nhưng nó không làm cho môi trường đơn giản hơn, nó chỉ hoạt động trong môi trường đơn giản. Trong phát triển quy mô lớn hơn, bạn sẽ rất vui khi bạn sử dụng công cụ tiêu chuẩn thay vì các giải pháp tùy chỉnh. Rốt cuộc, bạn chỉ phải học nó một lần (và khi trình quản lý gói du jour được thay thế bởi điều thú vị mới, bạn cũng phải học điều đó).

Bạn đang thiếu nhiều lợi thế của người quản lý gói.

1. Trình quản lý gói cho phép bạn tránh kiểm tra các tệp nhị phân lớn (vài megabyte hoặc lớn hơn) vào kiểm soát nguồn. Làm như vậy là vô cảm đối với nhiều công cụ kiểm soát nguồn, git phổ biến là một trong số đó. Chúng tôi đã có một kho lưu trữ đạt giới hạn kích thước của Bit Xô vài tháng trước vì các nhà phát triển đang kiểm tra Cốc Cốc. Một dự án khác đã đi được nửa đường khi chúng tôi di chuyển từ SVN vì chúng tôi đã kiểm tra tất cả các nhị phân lib của chúng tôi (và đã không sử dụng NuGet). Vì các nhà quản lý gói sẽ tải xuống các gói một cách nhanh chóng cho mỗi nhà phát triển, họ loại bỏ sự cần thiết phải kiểm tra các tệp nhị phân này.
2. Chúng ngăn trộn các tệp / thư viện không tương thích. Các thư mục có thể chứa các phiên bản hỗn hợp của các tệp của thư viện nếu ai đó không dọn dẹp đúng cách trong quá trình nâng cấp. Tôi đã thấy một trường hợp trong đó một nửa số nhị phân trong thư mục được nâng cấp, dẫn đến các lỗi rất kỳ lạ. (Nó thậm chí không sụp đổ!) Chúng tôi mất nhiều tháng theo nghĩa đen (không phải giờ đàn ông, chỉ là tổng thời gian) để tìm ra vấn đề. Bằng cách để trình quản lý gói kiểm soát toàn bộ thư mục, bạn không thể có các phiên bản hỗn hợp; bạn đảm bảo tính nhất quán. Chúng cũng khiến việc sử dụng các phụ thuộc không tương thích trở nên khó khăn hơn nhiều , bằng cách tự động cập nhật mọi thứ cùng nhau, cài đặt các phiên bản khác nhau khi cần hoặc thậm chí chỉ đưa ra các cảnh báo hoặc lỗi khi cố gắng sử dụng các phiên bản thư viện không tương thích.
3. Họ thiết lập một quy ước chung để quản lý thư viện. Khi các nhà phát triển mới đến dự án, nhóm, công ty của bạn, v.v., họ có khả năng biết các quy ước của người quản lý gói. Điều này có nghĩa là họ không phải lãng phí thời gian để tìm ra các chi tiết tốt về cách các thư viện được quản lý trong cơ sở mã của bạn.
4. Họ cung cấp cho bạn một cách chuẩn hóa phiên bản và phân phối các tệp và tệp phụ thuộc của riêng bạn không thuộc về kho lưu trữ của bạn. Tôi thậm chí đã tận dụng chúng cho một số tệp dữ liệu tĩnh lớn mà ứng dụng của tôi yêu cầu, vì vậy nó hoạt động tốt để phiên bản mọi thứ bên cạnh mã nhị phân.
5. Một số trình quản lý gói cung cấp các tính năng bổ sung trong quá trình cài đặt. NuGet sẽ thêm các tệp phụ thuộc và tệp nội dung vào tệp csproj của bạn và thậm chí có thể thêm các thành phần cấu hình vào tệp cấu hình.
6. Các tệp danh sách gói của họ ghi lại các phiên bản của thư viện của bạn ở một nơi tập trung duy nhất. Tôi không phải nhấp chuột phải vào DLL và xem số phiên bản để tìm ra phiên bản nào của thư viện tôi đang sử dụng. Trong Python, tác giả thư viện có thể thậm chí không bao gồm số phiên bản trong các tệp py, vì vậy tôi thậm chí không thể nói phiên bản thư viện từ chúng.
7. Họ không khuyến khích cài đặt rộng rãi các phụ thuộc. Trình quản lý gói cung cấp một cách thông thường để cài đặt các phụ thuộc mà không cần trình cài đặt toàn cục . Khi các tùy chọn của bạn là thư mục lib và cài đặt toàn cầu, nhiều nhà phát triển thư viện sẽ chọn cung cấp thư viện chính của họ dưới dạng cài đặt toàn cầu thay vì các tệp nhị phân có thể tải xuống mà bạn phải tự thiết lập. . thư mục
8. Họ có xu hướng tập trung lưu trữ và phân phối. Bạn không còn phải phụ thuộc vào trang web của thư viện ngẫu nhiên đó. Nếu họ không hoạt động, trang web của người quản lý gói thành công vẫn có mọi phiên bản được tải lên. Các nhà phát triển cũng không phải săn lùng nhiều trang web chỉ để tải xuống các thư viện mới; họ có một nơi để tìm kiếm đầu tiên và thậm chí duyệt tìm các tùy chọn khác nhau. Việc sao chép các gói được tổ chức theo cách tiêu chuẩn cũng dễ dàng hơn so với việc lưu trữ thủ công các bản sao của mọi thứ từ các trang web đặc biệt.

Bạn cũng đang nói quá về giá trị của "lợi ích" của bạn.

1. Không cần công cụ bên ngoài để quản lý các gói.

   "Bên ngoài" để làm gì? Tôi kiểm tra thực thi NuGet vào kho của tôi. Đó là nhị phân duy nhất tôi cảm thấy ổn khi đăng nhập, vì nó nhỏ và có nghĩa là tôi không cần kiểm tra bất kỳ nhị phân nào khác.

   Pip không đặt ra vấn đề ở mặt trước này vì nó được gói với Python theo mặc định bây giờ và các thay đổi không tương thích ngược và ngược cực kỳ hiếm. Dù sao, bạn sẽ không phát triển mã Python mà không cài đặt Python bên ngoài vào dự án của bạn.

   Vào thời điểm họ đạt được sự chấp nhận rộng rãi, các nhà quản lý gói có xu hướng rất ổn định. Bạn không thể thoát khỏi mà không có một số loại công cụ được cài đặt toàn cầu cho hầu hết các dự án và một trình quản lý gói duy nhất là một yêu cầu trọng lượng khá nhẹ. Nó thường không cồng kềnh hơn nhiều so với cài đặt thời gian chạy ngôn ngữ.

2. Không cần kết nối internet để xây dựng.

   Tôi không thể kết nối với cơ sở dữ liệu của mình mà không có kết nối mạng. Nếu cơ sở dữ liệu được lưu trữ trên Amazon, tôi vẫn cần kết nối internet đầy đủ. Tôi cần kết nối Internet để đẩy và kéo các thay đổi thông qua kiểm soát nguồn; một máy chủ xây dựng không thể kiểm tra mã để xây dựng mà không có một số loại kết nối mạng. Bạn không thể gửi hoặc nhận e-mail mà không có. Bạn không thể tải xuống các thư viện để đặt chúng vào thư mục lib của bạn mà không cần một! Phát triển vĩnh viễn mà không có kết nối internet là hầu như không nghe thấy. Trong một số trường hợp hiếm khi cần thiết, bạn có thể giải quyết vấn đề này bằng cách tải các gói xuống vị trí mà người quản lý gói có thể tiêu thụ. (Tôi biết NuGet và pip khá vui khi lấy từ một thư mục đơn giản hoặc ổ đĩa mạng; tôi nghi ngờ hầu hết những người khác cũng có thể.)

3. Xây dựng nhanh hơn (không kiểm tra gói).

   30 giây trong quá trình xây dựng tự động và 5 giây trong quá trình xây dựng nhà phát triển địa phương là một sự đánh đổi tốt cho những lợi ích tôi đã nêu ở trên. Đây là những khung thời gian tầm thường thường không đáng xem xét so với các vấn đề mà lợi ích giải quyết được.

4. Môi trường đơn giản hơn (yêu cầu ít kiến ​​thức hơn).

   Dù sao, một công cụ để quản lý gói không có gì để quản lý thư viện thực sự không phải là một so sánh công bằng. Không có công cụ, bạn phải học bất kỳ quy trình tùy chỉnh nào mà dự án đang sử dụngđể quản lý các thư viện của nó. Điều này có nghĩa là bạn không bao giờ chắc chắn liệu kiến ​​thức hiện tại của bạn có áp dụng cho bất kỳ dự án mới nào bạn tiếp cận hay không. Bạn sẽ phải đối phó với bất kỳ cách tiếp cận hodgepodge nào mà ai đó nghĩ ra, hoặc tạo nên của riêng bạn. Đó có thể là một thư mục chứa tất cả các thư viện, hoặc nó có thể là một cái gì đó lạ hơn. Có lẽ để tránh kiểm tra các thư viện, ai đó đặt tất cả chúng vào ổ đĩa mạng và chỉ báo phiên bản duy nhất là tên thư mục. Làm thế nào là hoặc cài đặt toàn cầu thực sự tốt hơn? Để so sánh, một người quản lý gói cung cấp cho bạn một quy ước rõ ràng sẽ áp dụng trên hầu hết các dự án bạn gặp phải.

Chủ đề chung là họ cung cấp tính nhất quán, tài liệu và các tính năng không chỉ trong các dự án, mà thậm chí trên toàn bộ chúng. Điều này đơn giản hóa cuộc sống của mọi người.

Gần đây đã chuyển đổi sản phẩm của chúng tôi từ việc sử dụng các thư viện được tải xuống thủ công sang quản lý gói tự động với Nuget, tôi có thể nói rằng sử dụng trình quản lý gói có lợi ích lớn.

Sản phẩm của chúng tôi được triển khai trên 27 dự án C #, tương đối nhỏ theo tiêu chuẩn ngày nay. Một số phụ thuộc bên thứ ba của chúng tôi có hàng chục hội đồng.

Trước Nuget, nếu tôi muốn cập nhật tất cả các phụ thuộc của chúng tôi lên phiên bản mới nhất, tôi sẽ phải:

1. Theo dõi nơi tôi có thể nhận được tất cả các thư viện cập nhật
2. Tải về chúng và giải nén / cài đặt
3. Thêm các phiên bản mới để kiểm soát nguồn
4. Xem thủ công tất cả các tài liệu tham khảo trong các dự án của chúng tôi và cập nhật chúng để chỉ ra các hội đồng mới

Với 27 dự án và hàng chục hội đồng phụ thuộc, quá trình này rất dễ bị lỗi và có thể mất nhiều giờ.

Bây giờ chúng tôi đã cập nhật để sử dụng Nuget, tất cả chỉ hoàn thành với tôi bằng một lệnh.

Không cần công cụ bên ngoài để quản lý gói

Đó là một điểm không phải là nó? Nếu tôi sử dụng trình quản lý gói, tôi không cần phải có thư mục lib. Tôi cũng không phải tự quản lý các gói.

Không cần kết nối internet để xây dựng

Bên cạnh việc không có kết nối internet ngày hôm nay trong khi phát triển là hơi hiếm (có thể ngoại trừ quá cảnh), một người quản lý gói tốt không nên yêu cầu bạn phải có phiên bản mới nhất để xây dựng ứng dụng của mình. Nó có thể phàn nàn, nhưng không có lý do gì để không xây dựng với phiên bản mà nó đã cài đặt

Xây dựng nhanh hơn (không kiểm tra gói)

Đó là một tốc độ khá nhanh, nhưng bạn có thể tranh luận về điều đó.

Môi trường đơn giản hơn (ít kiến ​​thức hơn)

Hầu hết các nhà quản lý gói ngày nay rất đơn giản đến nỗi hầu như không đáng để cố gắng khắc phục bằng cách thực hiện những điều này. Thậm chí có khách hàng trực quan nếu bạn muốn. Họ thực sự che giấu rất nhiều các croft đang diễn ra.

Quản lý gói cũng cho phép bạn chia sẻ các gói này giữa các dự án khác nhau. Nếu 5 dự án của tôi sử dụng cùng một phiên bản Boost, thì không cần phải sao chép dự án này cho từng dự án. Điều này đặc biệt đúng đối với các cây phụ thuộc phức tạp mà bạn nói đến.

Với thư mục lib, bạn chỉ quản lý các gói cho dự án đó, trong khi trình quản lý gói cho phép bạn thực hiện việc này cho toàn bộ môi trường phát triển của mình bằng một công cụ duy nhất.

Đó là sự khác biệt giữa việc chỉ sử dụng các thư viện ( thư mục lib) và sử dụng chúng, duy trì thông tin meta (trình quản lý gói) . Thông tin meta như vậy liên quan đến số phiên bản, phụ thuộc (bắc cầu) giữa các thư viện và như vậy.

Các cuộc thảo luận về địa ngục DLL, khả năng tương thích thư viện, hệ thống mô-đun java, OSGi và ít nhất cũng đủ sức thuyết phục về một số giá trị của việc có một số hình thức quản lý phụ thuộc.

• Phiên bản thư viện và các vấn đề phụ thuộc có thể là một sự lãng phí thời gian.

Ngoài ra còn có lợi ích của kho lưu trữ được chia sẻ (cục bộ), vì vậy một số dự án không cần duy trì các bản sao của libs đã nhập. Nếu một người có một dự án với 20 mô hình con, một số mô-đun có 40 phụ thuộc lẻ.

• Thêm cấu trúc
• Cắt tỉa thêm các thư viện
• Không có quyết định đặc biệt của con người về thư viện

Có một số trường hợp có thể cần một thư mục lib, ví dụ như khi xử lý các thư viện lỗi thời (một phiên bản của nó không còn được duy trì / khả dụng), một phiên bản thư viện được sửa đổi cục bộ, ...

Nhưng đối với mọi thứ khác, nó giống như nhà phát triển đảm nhận vai trò của người quản lý gói:

• Nhà phát triển sẽ phải tải xuống các thư viện (yêu cầu internet)
• Nhà phát triển sẽ phải kiểm tra các bản phát hành mới hơn bằng tay
• ...

Và IMHO, đó là kiến ​​thức cần ít hơn, bởi vì bạn phải tìm hiểu về việc sử dụng công cụ bên ngoài, nhưng ít hơn về các thư viện (tức là phụ thuộc).

Có một vấn đề khác không được đề cập bởi các câu hỏi khác: chia sẻ deps.

Giả sử, bạn có hai gói xây dựng cùng một thư viện. Trong trường hợp tốt nhất, sẽ không có bất kỳ đồng tiền nào, nhưng cùng một không gian ổ cứng / SSD được sử dụng hai lần. Trong trường hợp xấu nhất, sẽ có xung đột varios, như các phiên bản.

Nếu bạn sử dụng trình quản lý gói, nó sẽ chỉ cài đặt thư viện một lần (mỗi phiên bản) và đã cung cấp đường dẫn đến nó.

PS: tất nhiên, bạn cần liên kết động (hoặc chức năng tương tự trong ngôn ngữ của bạn) để có được pro này.

Một lý do chính tại sao các thư viện dùng chung được coi là một mục tiến bộ trong các hệ thống Unix và Windows thời kỳ 90 là cách chúng có thể giảm mức sử dụng RAM khi nhiều chương trình sử dụng cùng một bộ thư viện được tải. Không gian mã chỉ cần được phân bổ ONCE cho mỗi thư viện chính xác và phiên bản của thư viện đó , việc sử dụng bộ nhớ theo thể hiện duy nhất còn lại là cho các biến tĩnh.

Nhiều hệ điều hành triển khai các thư viện dùng chung theo cách phụ thuộc vào các cơ chế như api unix mmap () ngụ ý rằng một thư viện sẽ không chỉ cần phải là cùng một phiên bản mà thực sự là cùng một FILE. Điều này chỉ đơn giản là không thể tận dụng tối đa lợi thế cho một chương trình vận chuyển bộ thư viện của riêng mình.

Cho rằng bộ nhớ rẻ hơn rất nhiều và các phiên bản thư viện cần đa dạng hơn so với thập niên 90, cuộc tranh luận này không mang nhiều trọng lượng như ngày nay.