Mengapa perpustakaan dikirimkan secara terpisah dan bukan dibundel dengan setiap program?

Saya tahu mengapa ini bagus secara umum: perbaikan keamanan yang lebih cepat, pengemasan yang lebih mudah, lebih banyak fitur. Namun, saya mencoba meyakinkan beberapa rekan kerja bahwa kita tidak perlu menggabungkan perpustakaan dengan program kita. Ini tidak akan berfungsi tanpa perpustakaan ini, tetapi perpustakaan telah stabil untuk sementara waktu sekarang dan akan tetap demikian untuk masa mendatang. Saya tidak melihat alasan untuk TIDAK membatalkannya.

Argumen apa yang bisa saya gunakan untuk meyakinkan mereka?

Situasi spesifik saya adalah ini: Saya sedang mengerjakan SymPy , yang merupakan perpustakaan Python open-source untuk matematika simbolik. Bagian inti dari itu adalah mpmath , yang merupakan perpustakaan untuk aritmatika floating point multi-previsi. SymPy tidak berfungsi tanpa mpmath, tidak ada alternatif. Karena itu, telah dibundel dengan SymPy sejak awal (saya diberitahu bahwa biasanya ada sedikit ketidakcocokan untuk memperbaiki setiap kali versi baru diimpor). Juga harus dicatat bahwa pengembang mpmath dulu terlibat dalam pengembangan SymPy. Sekarang ada masalah pada unbundling mpmath, Anda dapat membaca semuanya di sini .

Untuk meringkas diskusi di sana:

Membatalkan ikatan:

• Agak lebih mudah porting ke Python 3 (argumen minor IMHO)

• Kemasan lebih mudah untuk distribusi

• Pembaruan fitur (keamanan) yang lebih cepat untuk pengguna

• "Pengemasan dan penanganan dependensi adalah masalah yang sulit, tetapi mereka diselesaikan. Ini jelas bukan bidang di mana kita harus melakukan hal kita sendiri."

Simpan bundling:

• Instalasi. Sangat mudah di Linux, lebih keras di Mac dan sangat keras di Windows. Kurangnya akses su dan masalah lainnya.

• itu adalah bagian integral dari SymPy, yaitu sympy tidak bekerja tanpanya (sama sekali)

• tidak ada paket lain, yang dapat melakukan pekerjaan mpmath

• "Ketika saya, sebagai pengguna, mengunduh sympy, saya berharap itu hanya berfungsi."

Itulah situasi khusus saya, tetapi saya akan menerima jawaban yang memberikan jawaban umum yang baik juga.

Namun jawaban lain, tetapi yang saya anggap paling penting (hanya pendapat pribadi saya), meskipun yang lain semua adalah jawaban yang baik juga.

Pengemasan lib secara terpisah memungkinkan lib diperbarui tanpa perlu memperbarui aplikasi. Katakan ada bug di lib, alih-alih hanya dapat memperbarui lib, Anda harus memperbarui seluruh aplikasi. Yang berarti aplikasi Anda akan memerlukan versi versi tanpa kodenya bahkan berubah, hanya karena lib.

Selain kelebihan yang Anda sebutkan (keamanan, pengemasan, fitur), saya dapat memikirkan beberapa hal lagi:

• Seseorang yang akan menemukan fungsionalitas berguna untuk program lain tidak perlu melakukan pekerjaan membaginya. Itu jika dia bahkan tahu jika fungsi ada di proyek Anda dalam bentuk perpustakaan di tempat pertama. Ini tergantung pada seberapa baik itu dirancang ... jika proyek Anda cukup modular.

• Dalam hal ini berguna untuk proyek lain, ini akan mengurangi ukuran penggunaan disk secara umum (misalnya hanya satu salinan kode).

• Ini akan meningkatkan kualitas kode Anda, memaksa Anda untuk melakukan beberapa refactoring (sangat dibutuhkan). Seperti pada poin pertama di atas, ini juga tergantung pada kualitas kode Anda.

• Meningkatkan jumlah pengguna perpustakaan (jika dipisah) akan membantu membuatnya lebih umum, yang kemungkinan akan meningkatkan kualitasnya juga.

Meskipun keuntungannya jelas, kemudahan penyebaran tampaknya menjadi argumen utama untuk pengiriman perpustakaan bersama dengan program dalam kasus Anda.

Berikut beberapa argumen yang menentang bundling:

• Di Linux, ini adalah tugas pengelola distribusi untuk memastikan bahwa perpustakaan Anda berfungsi baik dengan dependensinya. Kebanyakan pengguna akan mengunduh perpustakaan menggunakan manajer paket distribusi. Mereka yang menggunakan trunk biasanya tidak akan keberatan menghabiskan waktu mengkonfigurasi perpustakaan.

• Di Windows dan Mac OS, manajer paket Python seperti pip biasanya digunakan, karena menginstal pustaka dengan tangan itu rumit.

• Bahkan ada argumen tentang penggunaan-keras untuk mesin aplikasi Google, tetapi tidak semua kerangka web berjalan di atasnya. Banyak yang bahkan membutuhkan porting, ruang disk untuk perpustakaan terbatas, dan hosting aplikasi web itu memang! Tidak mungkin aplikasi web menggunakan matematika simbolik.

• Tidak ada yang mencegah Anda menampilkan pesan kesalahan bersih jika ketergantungan tidak tersedia atau memiliki versi yang salah.

• Orang-orang sering membencinya ketika program menganggap dirinya lebih pintar daripada mereka. Biarkan pengguna mengurus sistem mereka sendiri.

Cara yang tepat untuk menangani unbundled dalam paket installer windows adalah dengan melakukan tes awal untuk keberadaan perpustakaan, dan jika tidak hadir untuk menawarkan untuk menginstalnya dari paket library yang Anda sertakan dalam paket installer perangkat lunak. Saya cukup yakin sebagian besar aplikasi GTK yang memiliki port windows melakukan sesuatu di sepanjang baris ini - saya tahu pidgin melakukannya.

Satu ukuran tidak harus cocok untuk semua.

Untuk distribusi sumber, jika Anda bundel, pemaket pada banyak distribusi (setidaknya dari warisan Debian dan Fedora) harus melakukan pekerjaan tambahan untuk menonaktifkan atau menghapus bundling, karena kebijakan paket untuk platform tersebut melarang atau setidaknya sangat mencegah bundling. Karena itu, dengan bundling Anda menciptakan lebih banyak pekerjaan untuk hilir Anda dengan manfaat yang sangat sedikit. Mungkinkah argumen itu berbobot?

Distribusi biner (jika Anda menyediakannya) dapat berjalan baik; bundling mungkin masuk akal bagi mereka, karena mereka tidak digunakan oleh hilir.

Tetapi tidak ada alasan mengapa Anda tidak dapat membuat keputusan dan bundel yang berlawanan untuk installer Windows dan Mac.

Bundling vs ketergantungan adalah perdebatan lama di dunia pengemasan. Dokumen ini menceritakan tentang dua aliran pemikiran ini: http://www.aosabook.org/en/packaging.html