Tại sao các thư viện được vận chuyển riêng thay vì đi kèm với mọi chương trình?

Tôi biết tại sao điều này nói chung là tốt: sửa lỗi bảo mật nhanh hơn, đóng gói dễ dàng hơn, nhiều tính năng hơn. Tuy nhiên, tôi đang cố gắng thuyết phục một số đồng nghiệp rằng chúng tôi không cần phải gói một thư viện với chương trình của chúng tôi. Nó sẽ không hoạt động nếu không có thư viện này, nhưng thư viện đã ổn định trong một thời gian và sẽ duy trì như vậy trong tương lai gần. Tôi không thấy bất kỳ lý do nào KHÔNG giải quyết nó.

Tôi có thể sử dụng những lý lẽ nào để thuyết phục họ?

Tình huống cụ thể của tôi là thế này: Tôi đang làm việc trên SymPy , một thư viện Python mã nguồn mở cho toán học tượng trưng. Một phần cốt lõi của nó là mpmath , là một thư viện cho số học dấu phẩy động đa phổ. SymPy không hoạt động mà không có mpmath, không có sự thay thế nào. Do đó, nó đã được đóng gói với SymPy kể từ khi bắt đầu (tôi được cho biết rằng thường có sự không tương thích nhỏ để sửa mỗi khi một phiên bản mới được nhập). Cũng cần lưu ý rằng nhà phát triển mpmath đã từng tham gia phát triển SymPy. Bây giờ có một vấn đề về việc giải quyết mpmath, bạn có thể đọc tất cả ở đây .

Để tóm tắt các cuộc thảo luận ở đó:

Giải quyết:

• Việc chuyển sang Python 3 dễ dàng hơn (đối số nhỏ IMHO)

• Bao bì dễ dàng hơn để phân phối

• Cập nhật tính năng (bảo mật) nhanh hơn cho người dùng

• "Đóng gói và xử lý các phụ thuộc là những vấn đề khó khăn, nhưng chúng đã được giải quyết. Đây chắc chắn không phải là một lĩnh vực mà chúng ta nên làm việc của riêng mình."

Giữ bó:

• Cài đặt. Nó dễ với Linux, khó hơn trên Mac và rất khó với Windows. Thiếu quyền truy cập su và các vấn đề khác.

• nó là một phần không thể thiếu của SymPy, tức là sympy không hoạt động mà không có nó (tất cả)

• có không gói khác, mà có thể thực hiện công việc của mpmath

• "Khi tôi, với tư cách là người dùng, tải xuống sympy, tôi hy vọng nó chỉ hoạt động."

Đó là tình huống cụ thể của tôi, nhưng tôi cũng chấp nhận một câu trả lời cung cấp một câu trả lời chung chung, tốt.

Còn một câu trả lời khác, nhưng một câu tôi coi là quan trọng nhất (chỉ là ý kiến ​​cá nhân của riêng tôi), mặc dù những câu khác đều là câu trả lời tốt.

Đóng gói lib riêng biệt cho phép lib được cập nhật mà không cần cập nhật ứng dụng. Giả sử có một lỗi trong lib, thay vì chỉ có thể cập nhật lib, bạn phải cập nhật toàn bộ ứng dụng. Điều đó có nghĩa là ứng dụng của bạn sẽ cần một phiên bản nâng cấp mà không có mã của nó thậm chí đã thay đổi, chỉ vì lib.

Ngoài những ưu điểm bạn đã đề cập (bảo mật, bao bì, tính năng), tôi có thể nghĩ thêm một số:

• Ai đó sẽ tìm thấy chức năng hữu ích cho một chương trình khác sẽ không cần phải thực hiện công việc tách nó ra. Đó là nếu cô ấy thậm chí biết nếu chức năng tồn tại trong dự án của bạn ở dạng thư viện ở nơi đầu tiên. Điều này phụ thuộc vào mức độ thiết kế của nó ... nếu dự án của bạn đủ mô-đun.

• Trong trường hợp điều này hữu ích cho các dự án khác, điều này sẽ làm giảm kích thước sử dụng đĩa nói chung (ví dụ: chỉ một bản sao của mã).

• Điều này sẽ cải thiện chất lượng mã của bạn, buộc bạn phải thực hiện một số tái cấu trúc (rất cần thiết). Như ở điểm đầu tiên ở trên, điều này cũng phụ thuộc vào chất lượng mã của bạn.

• Việc tăng số lượng người dùng của thư viện (nếu tách ra) sẽ giúp làm cho nó chung chung hơn, điều này cũng có khả năng cải thiện chất lượng của nó.

Mặc dù lợi thế là rõ ràng, dễ triển khai dường như là đối số chính cho thư viện vận chuyển cùng với chương trình trong trường hợp của bạn.

Dưới đây là một số đối số chống lại gói:

• Trong Linux, đó là công việc của người bảo trì phân phối để đảm bảo rằng thư viện của bạn hoạt động tốt với các phụ thuộc của nó. Hầu hết người dùng sẽ tải xuống thư viện bằng trình quản lý gói phân phối. Những người đang sử dụng trunk thường không ngại dành thời gian cho việc cấu hình thư viện.

• Trong Windows và Mac OS, các trình quản lý gói Python như pip thường được sử dụng, vì cài đặt thư viện bằng tay rất cồng kềnh.

• Thậm chí đã có những tranh luận về việc triển khai cứng cho công cụ ứng dụng Google, nhưng không phải tất cả các khung web đều chạy trên nó. Nhiều người thậm chí còn yêu cầu chuyển, không gian đĩa cho các thư viện bị hạn chế và đó là ứng dụng lưu trữ web! Ứng dụng web không thể sử dụng toán học tượng trưng.

• Không ai ngăn bạn hiển thị thông báo lỗi sạch nếu phụ thuộc không có sẵn hoặc có phiên bản sai.

• Mọi người thường ghét nó khi chương trình tự coi mình thông minh hơn họ. Hãy để người dùng chăm sóc hệ thống của riêng họ.

Cách thích hợp để xử lý chưa được xử lý trong gói trình cài đặt windows sẽ là kiểm tra trước cho sự tồn tại của thư viện và nếu không có mặt để đề nghị cài đặt nó từ gói thư viện mà bạn đưa vào gói trình cài đặt phần mềm. Tôi khá chắc chắn rằng hầu hết các ứng dụng GTK có cổng windows đều làm được điều gì đó dọc theo các dòng này - tôi biết pidgin cũng vậy.

Một kích thước không phải phù hợp với tất cả.

Đối với các bản phân phối nguồn, nếu bạn đóng gói, đóng gói trên nhiều bản phân phối (ít nhất là các di sản của Debian và Fedora) sẽ phải thực hiện thêm công việc để vô hiệu hóa hoặc gỡ bỏ gói, vì các chính sách gói cho các nền tảng đó cấm hoặc ít nhất là không khuyến khích gói. Do đó, bằng cách gói bạn đang tạo ra nhiều công việc hơn cho hạ lưu của bạn với rất ít lợi ích. Có thể lập luận đó có trọng lượng?

Phân phối nhị phân (nếu bạn cung cấp chúng) có thể đi theo bất kỳ cách nào; bó có lẽ có ý nghĩa đối với những người, vì chúng không được sử dụng bởi hạ lưu.

Nhưng không có lý do tại sao bạn không thể đưa ra quyết định ngược lại và gói cho trình cài đặt Windows và Mac.

Đóng gói so với phụ thuộc là một cuộc tranh luận cũ trong thế giới bao bì. Tài liệu này nói về hai trường phái tư tưởng này: http://www.aosabook.org/en/packaging.html