Mengapa memilih manajer paket daripada folder perpustakaan?

68

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?

Ignacio Soler Garcia
sumber
33
Saya pikir Anda benar-benar bertanya tentang manfaat bundling vs membutuhkan perpustakaan. Anda akan mendapatkan jawaban yang lebih relevan jika menggunakan istilah itu.
Kilian Foth
3
Apa yang mencegah Anda membuat wadah buruh pelabuhan untuk agen pembangunan, berisi semua yang dibutuhkan dan bahkan mungkin tidak memungkinkan akses internet sama sekali (yang seharusnya tidak diperlukan untuk membangun)? Saya pikir Anda lebih menentang mempelajari alat baru daripada benar-benar mempertimbangkan argumen. Pernahkah Anda mengerjakan proyek besar yang menggunakan dependensi yang dikelola tangan? Ini tidak sehebat yang terlihat.
Kayaman
3
@ Kayaman: mempelajari alat baru membutuhkan waktu (uang) tim dan saya ingin memverifikasi bahwa kami menginvestasikannya dalam hal yang benar. Pengalaman saya dengan proyek-proyek besar adalah bahwa dependensi cukup stabil [mereka hampir tidak pernah berubah] dan itulah mungkin mengapa manajer paket tampak mahal bagi saya. Pokoknya saya hanya daftar pro dan kontra setelah bekerja sebentar dengan Nuget dan menghabiskan waktu dengan itu.
Ignacio Soler Garcia
2
@sebkur Anda dapat menyimpan salinan lokal dari semua paket Anda. Kami menjaga versi saat ini dari semua dependensi kami di bawah kendali sumber lokal. Satu-satunya saat manajer paket memerlukan koneksi adalah ketika kami melakukan peningkatan.
17 dari 26
1
@ 17of26: Anda tidak belajar cara mengkonfigurasi agen pembangun untuk menginstal nuget dan menjalankannya berdasarkan permintaan dalam 10 menit. Baik Anda lakukan jika Anda memiliki proyek multi solusi di mana proyek yang sama digunakan dalam solusi yang berbeda.
Ignacio Soler Garcia

Jawaban:

122

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.

sleske
sumber
170
“Tidak perlu alat eksternal untuk mengelola paket” - ya. Sekarang adalah tugas otak Anda. Semoga beruntung, otak!
Paul D. Waite
57
Siapa pun yang serius berpikir bahwa memiliki folder lib adalah "lingkungan yang lebih mudah" harus langsung saja mencoba dan mencari tahu pohon dependensi untuk mengatakan nuget Microsoft.AspNetCore.All . Ayo, jangan tunggu aku, aku akan kembali sekitar satu hari.
Voo
13
Juga, peramban internet yang Anda gunakan untuk memburu perpustakaan secara manual akan dihitung sebagai alat eksternal untuk mengelola paket. Bersamaan dengan semua yang Anda gunakan (manajer file OS, dll.) Untuk mempersiapkan dan memposisikan perpustakaan. Jadi pilihan sebenarnya adalah satu alat eksternal (manajer paket) vs banyak.
NemesisX00
3
Hanya FYI, saya baru-baru ini mencoba untuk bekerja dengan gradle pada PC offline. Tidak berhasil, Android Studio tidak akan menjalankan aplikasi saya dan saya mendapatkan pesan kesalahan yang tidak jelas dan itu setelah saya melakukan proses awal online untuk dependensi. Ini hanya dalam situasi seperti ini ketika Anda benar-benar melihat betapa tergantung pada manajer paket membuat perangkat lunak menjadi ...
FRob
7
@ PaulD.Waite Sementara kami berada di itu, kami menyingkirkan "bahasa" sial semua orang sedang terjadi. Semua itu akhirnya bermuara pada kode mesin, jadi di perusahaan saya, kami memotong perantara. Nah, itu efisiensi!
corsiKa
39

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).

Kayaman
sumber
21
@IgnacioSolerGarcia: Hanya lebih mudah jika tidak ada yang salah. Bagaimana jika perpustakaan A versi baru juga membutuhkan B dan C yang diperbarui? Bagaimana jika Anda masih berjalan, tetapi memperkenalkan bug halus? Itu semua adalah bagian dari "mengelola ketergantungan".
sleske
18
@IgnacioSolerGarcia mengatakan "unduh file" tidak cukup melukis gambar yang benar. Katakanlah "unduh 20 file dan pastikan versinya kompatibel". Tidak ada pekerjaan yang dihindari di sana. Memutakhirkan paket juga bukan situasi teoretis, kecuali Anda telah memutuskan untuk membekukan versi dependensi dan siap menerima masalah yang mungkin terjadi (bug, kelemahan keamanan) yang dihasilkan dari itu.
Kayaman
12
@IgnacioSolerGarcia "unduh file" - maksud Anda (1) menemukan situs web proyek yang benar (beberapa di-host di github, beberapa di sourceforge, beberapa di situs web mereka sendiri), (2) buka halaman pengunduhan, (3) cari versi yang benar , (4) unduh, (5) unzip dan letakkan di suatu tempat. Tampaknya itu jauh lebih berhasil daripada blah install libfoo. Dan kemudian, kalikan dengan, katakanlah, 5 dependensi.
el.pescado
5
@IgnacioSolerGarcia Ok file mana yang "cukup" harus saya unduh agar nuget ini berfungsi dengan baik? Dan itu pada dasarnya pengaturan paling sepele untuk proyek Core ASP.NET. Dalam praktiknya Anda akan memiliki lebih banyak dependensi.
Voo
6
@Ignacio Itulah nuget meta dasar untuk menjalankan dan menjalankan aplikasi ASP.Net Core yang paling sederhana. Benar di masa lalu yang baik dari kerangka penuh semuanya menjadi "lebih mudah", karena Anda baru saja mendapatkan perpustakaan monolitik besar yang semuanya versi pada waktu yang sama dan merilis pembaruan membutuhkan waktu bertahun-tahun. Model itu pada dasarnya sudah usang karena alasan yang sangat baik tidak hanya di dunia .NET. Anda harus terbiasa dengan seluruh model banyak perpustakaan kecil melakukan satu hal tertentu dan jujur ​​menggunakan manajer paket adalah bagian termudah dari transisi.
Voo
35

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.

jpmc26
sumber
10
"Berkembang secara permanen tanpa koneksi internet hampir tidak pernah terjadi" Saya berharap saya tidak tahu yang lebih baik. Ada banyak pengembangan yang dilakukan dalam jaringan yang benar-benar terpisah karena alasan keamanan. Ya itu tentang menyenangkan seperti kedengarannya, tetapi itu benar-benar bisa dilakukan. Anda hanya perlu mengatur infrastruktur Anda sendiri untuk penyimpanan paket (yaitu umpan nuget Anda sendiri).
Voo
1
Meskipun memiliki infrastruktur sendiri sebenarnya adalah salah satu dari beberapa hal yang masuk akal dalam hal apapun: Anda tidak ingin dapat diandalkan pada infrastruktur eksternal. Jika yang satu itu tidak tersedia karena satu dan lain alasan, jauh lebih baik untuk memiliki mundur yang menjamin bahwa pengembang Anda dapat terus berkembang. (Dan sebelum ada yang memberi tahu saya bagaimana nuget.org atau npm atau <insert repo paket favorit> tidak akan pernah mengalami masalah seperti itu, mungkin pikirkan lagi .)
Voo
3
@IgnacioSolerGarcia Menetapkan per proyek atau per departemen atau per konvensi perusahaan tidak lebih baik daripada hanya memiliki konvensi yang diketahui semua orang tanpa diberi tahu. Selain itu, paket mengelola melakukan pekerjaan yang lebih baik untuk menegakkan konvensi, karena membuat mengikuti konvensi kurang bekerja daripada melanggar konvensi. Juga, seperti yang saya sebutkan, saya mengkomit NuGet secara langsung dan memohonnya dalam skrip build, jadi saya tidak perlu menginstalnya. Saya terus membangun instalasi server ke minimum yang benar-benar telanjang.
jpmc26
2
@ jpmc26 Karena daftar bernomor pertama Anda akan mendapat manfaat dari beberapa penekanan .
Søren D. Ptæus
1
@ SørenD.Ptæus Selesai.
jpmc26
16

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.

17 dari 26
sumber
Setuju, itulah poin 2 dari pro. Bagaimanapun mengubah ketergantungan adalah sesuatu yang jarang kita lakukan (mungkin karena kurangnya tes regresi otomatis yang tepat).
Ignacio Soler Garcia
9
Memperbarui dependensi adalah sesuatu yang jauh lebih menyakitkan untuk dilakukan jika Anda melakukannya secara teratur.
17 dari 26
1
Apakah tes ini otomatis? Berapa lama waktu yang dibutuhkan untuk berlari? Sekalipun dibutuhkan 24 jam untuk menjalankan rangkaian pengujian penuh, itu masih memungkinkan Anda untuk memperbarui dependensi setiap beberapa hari dengan sedikit penurunan (walaupun Anda mungkin tidak akan sering melakukannya dalam praktik). Bahkan jika itu manual dan tidak dapat dihindari, menggunakan instalasi manual Anda bisa menghabiskan waktu berhari-hari menjalankan tes hanya untuk mengetahui mereka gagal karena Anda melewatkan beberapa dependensi ketergantungan, maka Anda harus memulai dari awal lagi setelah menginstalnya, yang tidak akan terjadi menggunakan manajemen paket ...
Sean Burton
3
Apakah Anda tidak memerlukan tes regresi pada rilis perangkat lunak baru? Cukup perbarui dependensi ketika Anda sudah melakukan pengujian untuk rilis.
17 dari 26
4
"Kami tidak memiliki mereka sepenuhnya otomatis dan alat ini terlalu besar untuk melakukannya (mungkin butuh berbulan-bulan mengujinya atau mengotomasinya)" - ada masalah besar Anda. Tes-tes ini seharusnya sudah ada sejak awal. Masalah Anda bukan karena menggunakan manajer paket tidak memberikan manfaat, masalah Anda adalah bahwa konteks tempat Anda bekerja terlalu rusak dengan cara lain untuk memungkinkan Anda menikmatinya.
Semut P
14

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.

Athos vk
sumber
Tidak mudah untuk memiliki agen build yang dikonfigurasi untuk menginstal manajer paket selama build, untuk memulihkan dependensi dan sebagainya. Tidak diperlukan dengan folder lib.
Ignacio Soler Garcia
4
Saya pikir itu tergantung bahasa apa yang Anda gunakan. Dengan bahasa seperti Ruby atau Rust, manajemen paket terintegrasi dengan sangat baik sehingga menggunakannya sepenuhnya sepele.
Sean Burton
Yah saya ommited itu dengan sengaja untuk memiliki komentar yang lebih luas tapi saya berbicara secara khusus tentang NuGet, C # dan VSTS cloud.
Ignacio Soler Garcia
4
@Ignacio Apa pun sistem build yang Anda gunakan yang tidak membuatnya sepele untuk mengembalikan NuGets harus segera dibuang. Untungnya VSTS membuat ini semudah yang didapat ( dokumentasi ): Ada tugas pemulihan NuGet yang Anda arahkan ke file solusi Anda dan beri tahu apa sumber NuGet untuk digunakan - untuk proyek sederhana hanya menggunakan nuget.orgakan baik-baik saja (templat default harus sudah diatur dengan cara ini).
Voo
3
@Ben RVM bukan manajer paket. Manajer paket untuk Ruby adalah RubyGems. RVM mengelola versi Ruby itu sendiri, dan untuk itu rbenv lebih baik ...
Sean Burton
5

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
Joop Eggen
sumber
3

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).

FranMowinckel
sumber
4
Bahkan untuk pustaka usang atau modifikasi, semua manajer paket yang saya lihat sejauh ini menawarkan opsi untuk mengunggah dependensi lokal ke repositori lokal Anda. Tapi ok, di situlah Anda kehilangan beberapa pengalaman "itu bekerja secara otomatis".
Hulk
@ Hulk jika ini adalah perpustakaan open source maka Anda dapat (dan seharusnya, mungkin) hanya menerbitkan versi Anda dan dengan demikian membuatnya terlihat oleh manajer paket. Baik dengan mendorong modifikasi ke pengelola, atau dengan mengeluarkan garpu perpustakaan Anda sendiri.
leftaroundabout
Jika Anda telah memodifikasi pustaka yang pengelolanya tidak responsif terhadap patch mail, maka itu akan menjadi masalah mencari tahu bagaimana mengkonfigurasi manajer paket sehingga paket lain yang bergantung pada pustaka juga dapat dipenuhi dengan pustaka Anda yang dimodifikasi.
Damian Yerrick
1

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.

val
sumber
-5

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.

pemeras
sumber
4
Pertanyaan ini tidak berbicara tentang pustaka bersama tetapi dependensi pada folder pustaka.
Ignacio Soler Garcia
1
Ini tidak menjawab pertanyaan OP
esoterik