KENAPA GAK DEP AJA ?
Pada 2017, pengembangan dep dimulai sebagai percobaan resmi di Go Package Management. Jika percobaan berhasil, maka dep akan menjadi solusi resmi untuk manajemen paket. dep ini menjadi sangat penting untuk developer Go, Dep mengadopsi mekanisme manajer paket lain, seperti cargo atau bundler . dep memang menggunakan dua file konfigurasi — Gopkg.toml dengan dependensi, dan Gopgk.lock dengan hash dan versi paket. Dependensi disimpan di direktori vendor. Dengan Dep memungkinkan untuk menentukan secara spesifik nomor versi yang sangat fleksibel dan tangguh untuk dependensi berdasarkan versi yang diinginkan. Spesifikasi versi yang valid di dep adalah hal-hal seperti 1.5–1.7.0 (yaitu> = 1.5 dan <= 1.7.0) dan ~ 1.6.0 (yaitu> = 1.6 dan <1.7.0). Pada dep, versi dapat ditentukan lebih fleksibel dan kuat daripada di modul Go, yang hanya memungkinkan spesifikasi versi minimal yang diperlukan. Tim Go mengikuti percobaan dengan cermat, tetapi pada akhirnya tidak dimasukkan dalam standar Go karena beberapa anggota tidak yakin. Bagaimanapun, prinsip Go lama menyatakan “jika ragu, tinggalkan saja.” Namun, tim Go terus bekerja secara intensif pada subjek manajemen paket. Salah satu pendukung utama adalah Russ Cox, yang bertanggung jawab atas konsep-konsep penting untuk modul Go dan implementasi saat ini. Intinya, Russ Cox mengatakan bahwa fleksibilitas dan kekuatan dep sulit bagi pengguna untuk mengelola. Dalam praktiknya, mereka tidak memberikan hasil yang lebih baik daripada pendekatan nomor versi minimum dari modul Go. Fleksibilitas ini membutuhkan implementasi yang sangat kompleks dari alat manajemen paket itu sendiri, dengan biaya pemeliharaan dan kinerja. Perbandingan modul dan dep Go akan melampaui lingkup yang dibahas di sini, tetapi poin paling penting dapat ditemukan di utas Twitter Russ Cox ini . Namun, satu hal yang pasti: kerja sama antara komunitas Go dan tim Google Go tidak berhasil dengan baik. Untuk waktu yang lama, banyak pokok kritik tidak dikomunikasikan kepada komunitas dep dan Go. Di sisi lain, modul Go dirancang di ruang tertutup Googleplex dan komunitas tidak cukup terlibat. Tim internal Go juga melihat ini dan menjanjikan upaya yang lebih baik di masa depan. Mugo-mugo lebih terbuka, leres to mase :)
PERINTAH UTAMA UNTUK GO MODULE
Untuk mendownload package bisa menggunakan :
go get
Untuk update bisa menggunakango get -u. Sedangkan go get -u=patch, berfungsi mengupdate semua dependensi ke versi patch terbaru.
go mod init
Perintah ini menginisialisasi modul dalam direktori saat ini. Secara opsional, jalur modul dapat ditentukan mijsalkan go mod init namaprojectmu lalu akan terbentuk file go.mod module namaprojectmu
require (
golang.org/x/text v0.3.0
)
exclude github.com/go-stack/stack v1.6.0
replace (
github.com/go-stack/stack v1.4.0 => ../stack/
golang.org/x/text => github.com/pkg/errors v0.8.0
)
go mod tidy
Perintah tidy membuat project go milikmu lebih RAPI, Perintah ini mengatur ulang konfigurasi modul ke sumbernya. Dependensi yang tidak lagi diperlukan akan dihapus, Dependensi transitif atau di perlukan maka diperbarui dan dibersihkan.
go mod graph
Panggilan go mod graphmenampilkan list semua dependensi yang diperlukan. Pemilihan versi minimal sederhana dan dapat dimengerti, tetapi baru dan sangat berbeda dengan konsep di kargo Rust atau bundler Ruby . Seleksi Versi Minimal melayani prinsip pengulangan. Prinsip pengulangan berarti bahwa hasil dari versi tertentu tidak boleh berubah. Karenanya sebuah bangunan harus selalu dapat diulang dan menghasilkan hasil yang sama, terlepas dari apakah itu dilakukan hari ini atau dalam waktu satu tahun. Ini memberikan stabilitas dan keandalan dalam pengembangan. Tim Go dan Russ Cox secara khusus telah banyak mengerjakan konsep ini. Cox telah menganalisis, mengumpulkan data, membandingkan algoritma, dan mencoba banyak opsi. Entri blog Cox pada berbagai aspek modul Go sangat luas dan mutlak harus bagi siapa saja yang ingin tahu lebih banyak tentang topik ini.
LEBIH LANJUT MENGENAI GO MODULE
Sejauh ini, go.mod hanya berisi dependensi pada modul lain yang membutuhkan . Dengan mengecualikan versi tertentu dari modul lain dapat dikecualikan (lihat Daftar 1). Dalam keadaan darurat, penggantian modul juga dapat digunakan untuk mengganti modul dengan modul lain (lihat Listing 1). Dengan spesifikasi ganti “bad / thing” v1.3.0 => “good / thing” v1.5.2, kami mengganti modul bad / thing dalam versi v1.3.0 dengan module good / thing dalam versi v1.5.2. Untuk modul yang merupakan dependensi langsung, ini tidak masuk akal karena di sana kita dapat mengubah dependensi yang diperlukan secara langsung. Dengan dependensi tidak langsung, kami tidak dapat mengubah apa pun — penggantian adalah pilihan terakhir. Dengan mengharuskan, mengecualikan, dan mengganti versi modul tertentu, kami mempelajari semua kemungkinan konfigurasi modul. Sekarang, kita akan belajar lebih banyak tentang mengapa ini cukup dan apa yang terjadi secara internal. Tapi pertama-tama, sedikit perjalanan tentang versi dengan modul Go.