Peta ekosistem

Keputusan memilih pustaka bukan lagi keputusan kecil setelah jalur ini melewati QuickCheck, tasty, aeson, dan async, karena setiap proyek nyata tersusun dari puluhan paket semacam itu. Peta ekosistem Haskell bertumpu pada beberapa layanan yang perannya berbeda, yaitu Hackage sebagai katalog paket, Stackage sebagai layanan pengujian bersama, GHCup sebagai pemasang perkakas, dan pustaka inti yang menyertai GHC. Topik ini membahas pembagian peran itu beserta cara menilai kelayakan sebuah paket sebelum digunakan.

Hackage dan Stackage#

Hackage adalah katalog pusat paket Haskell, tempat setiap paket diunggah beserta dokumentasi yang dibangun otomatis, riwayat versinya, dan daftar dependensinya. Pencarian dan penelusuran versi berlangsung di sana, sehingga halaman paket pada Hackage menjadi titik awal alami ketika sebuah nama pustaka baru ditemukan.

Stackage bekerja di atas katalog itu dengan menyusun snapshot, yaitu kumpulan paket pada versi tertentu yang dibangun dan diuji bersama-sama. Snapshot LTS diterbitkan secara berkala dari hasil uji tersebut, dan paket yang gagal dibangun bersama ditunda sampai permasalahannya selesai. Perbedaan peran keduanya penting dipahami karena keduanya menjawab pertanyaan yang berbeda, sebagaimana dirangkum tabel berikut.

Pembagian ini juga menjelaskan perbedaan yang muncul pada topik Stack, yaitu penggunaan snapshot yang terkunci pada versi tertentu, karena versi-versi itu berasal dari hasil pengujian Stackage.

Menilai kelayakan paket#

Kelayakan sebuah paket dinilai dari beberapa sinyal yang terbaca pada halaman Hackage-nya, dan daftar berikut mengurutkannya dari yang paling menentukan.

• dokumentasi yang dibangun untuk versi terkini, karena kegagalan build dokumentasi sering menandakan paket yang jarang dirawat.
• tanggal unggah versi terakhir beserta riwayat versinya, sebagai gambaran apakah paket ini masih aktif atau sudah tertinggal di belakang versi GHC terkini.
• keikutsertaan pada snapshot Stackage terkini, karena masuknya berarti paket ini berhasil dibangun bersama ratusan paket lain.
• jumlah paket lain yang bergantung padanya, sinyal yang lazim disebut reverse dependency dan terbaca pada halaman paketnya.
• kelengkapan berkas sumber, seperti catatan perubahan dan lisensi, yang mencerminkan kedisiplinan pemeliharanya.

Kelima sinyal itu dibaca bersama, bukan satu per satu, karena masing-masing dapat menyesatkan apabila berdiri sendiri. Paket yang stabil dan matang bisa saja jarang diunggah ulang tanpa berarti terbengkalai, sedangkan paket yang diunggah minggu lalu belum tentu teruji pada kombinasi GHC yang digunakan proyek. Keikutsertaan pada Stackage menjadi penyeimbangnya, karena di sanalah kecocokan antarversi diuji secara nyata.

Pustaka inti dan pilar ekosistem#

Sebagian pustaka menyertai GHC sejak pemasangan dan tidak memerlukan instalasi, yaitu base yang memuat Prelude, text untuk teks, bytestring untuk urutan byte, serta containers untuk peta dan himpunan. Pustaka-pustaka ini menjadi fondasi yang sudah digunakan di sepanjang jalur ini, dan keberadaannya menjelaskan mengapa contoh-contoh awal tidak pernah memerlukan instalasi apa pun.

Di luar fondasi itu, empat paket telah menjadi pilar praktis pada jalur ini dan kebiasaan memilihnya dapat ditiru, yaitu QuickCheck dan tasty untuk pengujian, aeson untuk JSON, dan async untuk konkurensi. Keempatnya dipilih karena dipelihara aktif, terdokumentasi dengan baik, dan masuk snapshot Stackage, bukti kecil bahwa ketiga kriteria tersebut memang bekerja pada pilihan yang sudah diambil. Catatan yang menyertainya, keempat pustaka tersebut semuanya dipasang melalui Cabal dengan cara yang sama, sehingga kebiasaan alat dari jalur ini langsung berlaku tanpa penyesuaian baru.

Kesalahan umum#

Kesalahan pertama adalah menilai paket dari satu angka semata, misalnya jumlah unduhan, karena angka itu mencerminkan popularitas dan bukan kecocokan dengan proyek yang sedang dibangun. Paket populer pada rentang GHC lama tetap mengumpulkan unduhan sementara versi GHC terkininya belum teruji, keadaan yang hanya terbaca dari kombinasi sinyal pada halaman paketnya.

Kesalahan kedua berupa menambah dependensi tanpa menimbang biayanya. Setiap paket yang masuk build-depends membawa pohon dependensinya, dan pohon yang bertambah luas memperbesar kemungkinan konflik versi serta beban pemeliharaan. Kebiasaan yang sehat berupa memeriksa apakah kebutuhan itu sudah terjawab oleh pustaka inti atau paket yang sudah digunakan, sebelum menambah nama baru pada daftar dependensi.

Ringkasan#

• Hackage menjadi katalog paket dan dokumentasi, Stackage menguji paket bersama dan menerbitkan snapshot, sedangkan GHCup memasang perkakas.
• Kelayakan paket dinilai dari kombinasi sinyal, yaitu dokumentasi, riwayat versi, keikutsertaan Stackage, dan dependensi terbalik, bukan dari satu angka.
• Pustaka inti seperti base, text, bytestring, dan containers menyertai GHC, sedangkan pilar praktis seperti QuickCheck, tasty, aeson, dan async dipasang melalui Cabal.
• Menambah dependensi berarti menambah pohon yang harus tetap cocok, sehingga kebutuhan baru diperiksa terlebih dahulu terhadap yang sudah ada.

Referensi#

• Hackage: packages — hackage.haskell.org — Katalog paket beserta penelusuran versi dan dokumentasinya.
• Stackage — stackage.org — Layanan snapshot dan hasil uji bersama ribuan paket Haskell.
• GHCup — haskell.org — Pemasang GHC, Cabal, HLS, dan Stack beserta versinya.
• Browse packages — hackage.haskell.org — Penelusuran paket menurut tag, abjad, dan tanggal unggah.