Mengapa memilih manajer paket daripada folder perpustakaan?

Ketika saya berpikir tentang pro dan kontra dari folder perpustakaan statis dan manajer paket saya merasa seperti folder perpustakaan adalah pendekatan yang lebih baik.

Pro saya melihat dengan folder perpustakaan:

1. Tidak perlu alat eksternal untuk mengelola paket.
2. Tidak diperlukan koneksi internet untuk membangun.
3. Build lebih cepat (tidak ada pengecekan paket).
4. Lingkungan yang lebih sederhana (lebih sedikit pengetahuan yang dibutuhkan).

Pro yang saya lihat dengan manajer paket:

1. Membantu dengan pohon dependensi yang kompleks (dan itu dapat dikelola dengan mengunduh dependensi bersama dengan semua dependensinya).
2. Membantu memeriksa apakah ada versi baru yang tersedia.

Tampaknya industri telah memutuskan untuk mengikuti jalur manajer paket untuk hampir semua yang dibangun hari ini. Jadi, apa yang saya lewatkan?

Poin penting yang hilang dari jawaban lain:

Menggunakan manajer paket berarti memiliki konfigurasi yang menunjukkan versi pustaka mana yang Anda gunakan dan memastikan bahwa informasi konfigurasi benar.

Mengetahui perpustakaan yang Anda gunakan, dan versi mana, sangat penting jika Anda:

• perlu memperbarui perpustakaan karena ada bug penting / lubang keamanan;
• atau hanya perlu memeriksa apakah lubang keamanan yang diumumkan mempengaruhi Anda.

Selain itu, ketika Anda benar-benar melakukan pembaruan, manajer paket (biasanya) memastikan setiap dependensi transitif diperbarui sesuai kebutuhan.

Sedangkan dengan libfolder, Anda hanya memiliki banyak file (mungkin biner, dan mungkin dimodifikasi), dan Anda harus menebak dari mana asalnya dan versi apa mereka (atau mempercayai beberapa README, yang mungkin atau mungkin tidak benar) ).

Untuk membahas poin Anda yang lain:

Tidak perlu alat eksternal untuk mengelola paket.

Benar, tetapi a) sebagai pengembang perangkat lunak Anda perlu menginstal banyak alat, jadi satu lagi biasanya tidak masalah, dan b) biasanya hanya ada satu atau beberapa manajer paket di bidang tertentu (Maven / Gradle untuk Jawa, npm untuk JS / TypeScript, dll), jadi Anda tidak perlu menginstalnya puluhan.

Tidak diperlukan koneksi internet untuk membangun.

Semua manajer paket yang saya kenal bekerja secara off-line, setelah mereka mengunduh dependensi yang diperlukan (yang dapat terjadi segera setelah mengunduh proyek itu sendiri).

Build lebih cepat (tidak ada pengecekan paket).

Mungkin benar, tetapi tampaknya pengecekan paket offline tidak akan memakan banyak waktu (hanya membandingkan beberapa nomor versi). Pemeriksaan daring mungkin memakan waktu cukup lama, tetapi itu dapat dimatikan jika diinginkan (jika bahkan diaktifkan secara default - Maven misalnya tidak pernah memeriksa pembaruan untuk versi rilis).

Lingkungan yang lebih sederhana (lebih sedikit pengetahuan yang dibutuhkan).

Benar, tetapi seperti yang dijelaskan di atas, libfolder juga membutuhkan pengetahuan. Juga, seperti dijelaskan di atas, Anda mungkin hanya akan bekerja dengan beberapa manajer paket yang berbeda, yang sudah Anda ketahui.

Kelebihan folder lib menghilang dengan cepat setelah Anda beralih dari pengembangan skala kecil ke pekerjaan yang lebih besar.

Misalnya, "manfaat" dari tidak memerlukan alat eksternal dikalahkan oleh pekerjaan yang diperlukan untuk mengelola dependensi Anda secara manual, sehingga alat itu akan menjadi Anda (dalam lebih dari satu pengertian dunia).

Anda tidak memerlukan koneksi internet untuk manajer paket. Anda dapat menggunakan repositori lokal.

Membangun lebih cepat mungkin benar, tetapi itu bukan sesuatu yang harus menentukan apakah akan menggunakan manajer paket atau tidak. Bagaimanapun, kita tidak membicarakan tentang besarnya perbedaan, dan ini juga tergantung pada konfigurasi Anda. Anda dapat dengan mudah membuat build lambat menggunakan manajer paket, tapi itu pada dasarnya sabotase.

Lingkungan yang lebih sederhana (lebih sedikit pengetahuan yang dibutuhkan)? Sekali lagi, dalam pengembangan skala kecil jelas merupakan suatu kemungkinan. Anda mungkin dapat memegang proyek sepenuhnya di kepala Anda, hingga masing-masing dari beberapa perpustakaan yang digunakan. Tambahkan makefile sederhana / skrip build lain dan Anda telah mendapatkan paket lengkap untuk diri Anda sendiri.

Tetapi itu tidak membuat lingkungan lebih sederhana, itu hanya bekerja di lingkungan yang sederhana. Dalam pengembangan skala yang lebih besar Anda akan senang bahwa Anda menggunakan perkakas standar alih-alih solusi khusus. Lagi pula, Anda hanya perlu mempelajarinya sekali saja (dan ketika manajer paket du jour digantikan oleh hal keren yang baru, Anda harus mempelajarinya juga).

Anda kehilangan banyak manfaat dari manajer paket.

1. Manajer paket memungkinkan Anda untuk menghindari memeriksa binari besar (beberapa megabyte atau lebih besar) ke dalam kontrol sumber. Melakukan hal itu adalah laknat bagi banyak alat kontrol sumber, git meresap menjadi salah satunya. Kami memiliki repositori hit batas ukuran Bit Bucket beberapa bulan yang lalu karena pengembang memeriksa di CocoaPods. Proyek lain sudah setengah jalan ketika kami bermigrasi dari SVN karena kami telah memeriksa semua binari lib kami (dan belum menggunakan NuGet). Karena manajer paket akan mengunduh paket dengan cepat untuk setiap pengembang, mereka menghilangkan keharusan untuk memeriksa binari ini di.
2. Mereka mencegah pencampuran file / pustaka yang tidak kompatibel. Folder dapat berisi versi campuran dari file perpustakaan jika seseorang tidak membersihkannya dengan benar selama pemutakhiran. Saya telah melihat kasus di mana setengah binari dalam folder ditingkatkan, menghasilkan bug yang sangat aneh. (Bahkan tidak crash!) Kami butuh waktu berbulan-bulan (bukan jam kerja, hanya waktu keseluruhan) untuk memecahkan masalah. Dengan membiarkan manajer paket mengontrol seluruh folder, Anda tidak bisa mendapatkan versi campuran; Anda memastikan konsistensi. Mereka juga membuat lebih sulit untuk menggunakan dependensi yang tidak kompatibel , dengan secara otomatis memperbarui semuanya bersama-sama, menginstal versi yang berbeda di mana diperlukan, atau bahkan hanya melemparkan peringatan atau kesalahan ketika mencoba menggunakan versi perpustakaan yang tidak kompatibel.
3. Mereka membangun konvensi bersama untuk mengelola perpustakaan. Ketika pengembang baru datang ke proyek Anda, tim, perusahaan, dll., Mereka cenderung mengetahui konvensi manajer paket. Ini berarti mereka tidak perlu membuang waktu untuk mencari tahu rincian tentang bagaimana perpustakaan dikelola di basis kode Anda.
4. Mereka memberi Anda cara standar untuk versi dan mendistribusikan dependensi dan file Anda sendiri yang tidak termasuk dalam repositori Anda. Saya bahkan secara pribadi memanfaatkannya untuk beberapa file data statis besar yang diperlukan aplikasi saya, jadi ini berfungsi dengan baik untuk versi hal selain kode biner.
5. Beberapa manajer paket menyediakan fitur tambahan selama instalasi. NuGet akan menambahkan file dependensi dan konten ke file csproj Anda dan bahkan dapat menambahkan elemen konfigurasi ke file konfigurasi.
6. File daftar paket mereka mendokumentasikan versi perpustakaan Anda di satu tempat terpusat. Saya tidak perlu mengeklik kanan DLL dan melihat nomor versi untuk mengetahui versi perpustakaan yang saya gunakan. Dalam Python, penulis perpustakaan mungkin bahkan tidak memasukkan nomor versi dalam file py, jadi saya mungkin bahkan tidak bisa memberi tahu versi perpustakaan dari mereka.
7. Mereka mencegah instalasi yang luas dari ketergantungan. Manajer paket menyediakan cara konvensional untuk menginstal dependensi tanpa installer global . Ketika opsi Anda adalah folder lib dan instalasi global, banyak pengembang perpustakaan akan memilih untuk menawarkan perpustakaan mereka primer sebagai instalasi global daripada sebagai binari yang dapat diunduh yang Anda harus atur sendiri. (Sejarah MS menunjukkan hal ini. Ini juga berlaku untuk banyak perpustakaan di Linux.) Ini sebenarnya membuat mengelola banyak proyek lebih sulit, karena Anda mungkin memiliki proyek dengan versi yang saling bertentangan dan beberapa pengembang pasti akan memilih pemasangan global yang tampaknya lebih sederhana daripada memiliki lib mereka sendiri. dir.
8. Mereka cenderung memusatkan hosting dan distribusi. Anda tidak lagi harus bergantung pada situs web perpustakaan acak itu. Jika mereka keluar dari bisnis, situs pengelola paket yang sukses masih memiliki setiap versi yang pernah diunggah. Pengembang juga tidak perlu memburu banyak situs web hanya untuk mengunduh perpustakaan baru; mereka memiliki tempat masuk untuk mencari pertama dan bahkan menelusuri berbagai opsi. Juga lebih mudah untuk mencerminkan paket yang diatur dengan cara standar daripada meng-host salinan segala sesuatu dari situs web ad-hoc secara manual.

Anda juga melebih-lebihkan nilai "manfaat" Anda.

1. Tidak perlu alat eksternal untuk mengelola paket.

   "Eksternal" untuk apa? Saya memeriksa executable NuGet ke dalam repositori saya. Ini satu-satunya biner yang saya rasa tidak apa-apa untuk check-in, karena kecil dan berarti saya tidak perlu memeriksa biner lain di dalamnya.

   pip tidak menimbulkan masalah di bagian depan ini karena dibundel dengan Python secara default sekarang dan memecah dan mundur perubahan yang tidak kompatibel sangat jarang terjadi. Anda tidak akan mengembangkan kode Python tanpa menginstal Python secara eksternal ke proyek Anda.

   Pada saat mereka mencapai adopsi luas, manajer paket cenderung sangat stabil. Anda tidak bisa pergi tanpa beberapa jenis perkakas diinstal secara global untuk sebagian besar proyek, dan manajer paket tunggal adalah persyaratan cukup berat ringan. Biasanya tidak jauh lebih rumit daripada menginstal runtime bahasa.

2. Tidak diperlukan koneksi internet untuk membangun.

   Saya tidak dapat terhubung ke database saya tanpa koneksi jaringan. Jika basis datanya adalah host Amazon, saya memerlukan koneksi internet penuh. Saya membutuhkan koneksi Internet untuk mendorong dan menarik perubahan melalui kontrol sumber; server build tidak dapat memeriksa kode untuk dibangun tanpa koneksi jaringan. Anda tidak dapat mengirim atau menerima email tanpa email . Anda tidak dapat mengunduh perpustakaan untuk meletakkannya di folder lib Anda tanpa perpustakaan! Pengembangan secara permanen tanpa koneksi internet hampir tidak pernah terjadi. Dalam beberapa kasus yang jarang terjadi jika diperlukan, Anda dapat mengatasinya dengan mengunduh paket ke lokasi yang dapat dikonsumsi oleh pengelola paket. (Saya tahu NuGet dan pip cukup senang untuk menarik dari folder sederhana atau drive jaringan; Saya kira kebanyakan orang juga bisa.)

3. Build lebih cepat (tidak ada pengecekan paket).

   30 detik selama pembuatan otomatis dan 5 detik selama pengembangan dev lokal merupakan pertukaran yang baik untuk manfaat yang saya sebutkan di atas. Ini adalah kerangka waktu sepele yang biasanya bahkan tidak layak dipertimbangkan dibandingkan dengan masalah yang dipecahkan manfaatnya.

4. Lingkungan yang lebih sederhana (lebih sedikit pengetahuan yang dibutuhkan).

   Bagaimanapun, satu alat untuk manajemen paket terhadap apa pun untuk manajemen perpustakaan sebenarnya bukan perbandingan yang adil. Tanpa alat, Anda harus mempelajari proses kustom apa pun yang digunakan proyekuntuk mengelola perpustakaannya. Ini berarti Anda tidak pernah yakin apakah pengetahuan Anda yang ada berlaku untuk proyek baru yang Anda dekati. Anda harus berurusan dengan pendekatan campur aduk apa pun yang dilakukan seseorang, atau buat pendekatan Anda sendiri. Itu mungkin direktori yang berisi semua perpustakaan, atau mungkin sesuatu yang jauh lebih aneh. Mungkin untuk menghindari memeriksa perpustakaan, seseorang meletakkan semuanya di drive jaringan dan satu-satunya indikator versi adalah nama folder. Bagaimana itu atau instalasi global benar-benar lebih baik? Sebagai perbandingan, manajer paket memberi Anda konvensi bersih yang akan berlaku di sebagian besar proyek yang Anda temui.

Tema umum adalah bahwa mereka memberikan konsistensi, dokumentasi, dan fitur tidak hanya dalam proyek, tetapi bahkan di seluruh proyek. Ini menyederhanakan kehidupan setiap orang.

Baru-baru ini mengubah produk kami dari menggunakan perpustakaan yang diunduh secara manual ke manajemen paket otomatis dengan Nuget, saya dapat mengatakan bahwa menggunakan manajer paket memiliki manfaat besar.

Produk kami diimplementasikan di 27 proyek C #, yang relatif kecil dari standar saat ini. Beberapa dependensi pihak ketiga kami memiliki puluhan majelis.

Sebelum ke Nuget, jika saya ingin memperbarui semua dependensi kami ke versi terbaru, saya harus:

1. Lacak di mana saya bisa mendapatkan semua perpustakaan yang diperbarui
2. Unduh dan unzip / instal
3. Tambahkan versi baru ke kontrol sumber
4. Lihatlah semua referensi di proyek kami secara manual dan perbarui untuk menunjuk ke majelis baru

Dengan 27 proyek dan puluhan majelis ketergantungan, proses ini sangat rawan kesalahan dan bisa memakan waktu berjam-jam.

Sekarang kami telah memperbarui untuk menggunakan Nuget, itu semua dilakukan untuk saya dengan satu perintah.

Tidak perlu alat eksternal untuk mengelola paket

Itu semacam tidak penting kan? Jika saya menggunakan manajer paket, saya tidak perlu memiliki folder lib. Saya juga tidak harus mengelola paket sendiri.

Tidak diperlukan koneksi internet untuk membangun

Selain itu tidak memiliki koneksi internet saat ini sementara pengembangan agak jarang terjadi (mungkin dengan pengecualian sedang dalam perjalanan), manajer paket yang baik seharusnya tidak mengharuskan Anda harus memiliki versi terbaru untuk membangun aplikasi Anda. Mungkin mengeluh, tetapi tidak ada alasan untuk tidak membangun dengan versi yang sudah diinstal

Build lebih cepat (tidak ada pengecekan paket)

Itu speedboost yang cukup marjinal, tetapi Anda bisa membuat poin untuk itu.

Lingkungan yang lebih sederhana (lebih sedikit pengetahuan yang dibutuhkan)

Sebagian besar manajer paket sangat sederhana akhir-akhir ini sehingga hampir tidak ada gunanya mencoba menyiasatinya dengan melakukan ini. Bahkan ada klien visual jika Anda mau. Mereka benar-benar menyembunyikan banyak croft yang sedang terjadi.

Manajer paket juga memungkinkan Anda untuk berbagi paket ini di antara berbagai proyek. Jika 5 proyek saya menggunakan versi Boost yang sama, tidak perlu menduplikasi ini untuk setiap proyek. Ini terutama berlaku untuk pohon dependensi kompleks yang Anda bicarakan.

Dengan folder lib Anda mengelola paket hanya untuk proyek itu, sementara manajer paket memungkinkan Anda melakukan ini untuk seluruh lingkungan pengembangan Anda dengan satu alat.

Ini adalah perbedaan antara hanya menggunakan perpustakaan (direktori lib) , dan menggunakannya, mempertahankan meta-informasi (manajer paket) . Informasi meta semacam itu menyangkut nomor versi, (transitif) ketergantungan antara perpustakaan dan semacamnya.

Diskusi neraka DLL, kompatibilitas perpustakaan, sistem modul java, OSGi dan semacamnya setidaknya harus cukup meyakinkan dari beberapa nilai memiliki beberapa bentuk manajemen ketergantungan.

• Versi perpustakaan dan masalah ketergantungan dapat menjadi buang-buang waktu.

Juga ada manfaat dari repositori bersama (lokal), sehingga beberapa proyek tidak perlu menyimpan salinan lib yang diimpor. Jika seseorang memiliki proyek dengan 20 submodul, beberapa modul memiliki 40 dependensi aneh.

• Lebih banyak struktur
• Lebih banyak pemangkasan perpustakaan
• Tidak ada keputusan manusia ad-hoc tentang perpustakaan

Ada beberapa kasus di mana folder lib mungkin diperlukan, misalnya ketika berhadapan dengan perpustakaan usang (versi itu tidak lagi dipertahankan / tersedia), versi perpustakaan yang dimodifikasi secara lokal, ...

Tetapi untuk yang lainnya, itu seperti pengembang yang berperan sebagai pengelola paket:

• Pengembang harus mengunduh perpustakaan (diperlukan internet)
• Pengembang harus memeriksa rilis yang lebih baru secara manual
• ...

Dan IMHO, itu kurang pengetahuan yang diperlukan, karena Anda harus belajar tentang penggunaan alat eksternal, tetapi lebih sedikit tentang perpustakaan (yaitu dependensi).

Ada masalah lain yang tidak dicakup oleh pertanyaan lain: berbagi deps.

Katakanlah, Anda memiliki dua paket yang membangun perpustakaan yang sama. Dalam kasus terbaik, tidak akan ada coflicts, tetapi ruang HDD / SSD yang sama digunakan dua kali. Yang terburuk, akan ada konflik varios, seperti versi.

Jika Anda menggunakan manajer paket, itu akan menginstal perpustakaan hanya sekali (per versi) dan sudah menyediakan path ke sana.

PS: tentu saja, Anda memerlukan tautan dinamis (atau fungsi serupa dalam bahasa Anda) untuk mendapatkan pro ini.

Salah satu alasan utama mengapa shared library dianggap sebagai item kemajuan di era 90-an sistem Unix dan Windows adalah bagaimana mereka dapat menurunkan penggunaan RAM ketika beberapa program menggunakan set library yang sama dimuat. Ruang kode hanya perlu dialokasikan SEKALI per perpustakaan yang tepat dan versi perpustakaan itu , satu-satunya penggunaan memori per-contoh yang tersisa adalah untuk variabel statis.

Banyak sistem operasi mengimplementasikan pustaka bersama dengan cara yang bergantung pada mekanisme seperti api unix mmap () - yang menyiratkan bahwa pustaka tidak hanya perlu versi yang persis sama tetapi juga FILE yang sama. Ini tidak mungkin untuk mengambil keuntungan penuh dari sebuah program yang mengirimkan set perpustakaannya sendiri.

Mengingat bahwa memori jauh lebih murah, dan versi perpustakaan dibutuhkan lebih beragam, daripada di tahun 90-an, argumen ini tidak membawa banyak bobot saat ini.