Artikel ditulis pada bulan Februari 2018.

Go perlu menambahkan versi paket.

Lebih tepatnya, Anda perlu menambahkan konsep versi ke kamus dan alat kerja pengembang Go sehingga semua orang menggunakan nomor versi yang sama ketika mereka menyebutkan program mana yang akan dibangun, dijalankan atau dianalisis. Perintah go harus mengatakan dengan tepat versi paket mana yang ada dalam rakitan tertentu.

Penomoran versi memungkinkan Anda membuat rakitan yang dapat direproduksi: jika saya memposting versi terbaru dari program saya, Anda tidak hanya akan mendapatkan versi terbaru dari kode saya, tetapi juga versi yang sama persis dari semua paket yang bergantung pada kode saya, sehingga kami akan membuat file biner yang sepenuhnya setara.

Versi juga memastikan bahwa besok program dibangun sama persis seperti hari ini. Bahkan jika versi dependensi baru dirilis, go tidak akan menggunakannya tanpa perintah khusus.

Meskipun Anda perlu menambahkan kontrol versi, Anda tidak boleh melepaskan keuntungan utama dari perintah go : itu adalah kesederhanaan, kecepatan dan pengertian. Saat ini, banyak programmer tidak memperhatikan versi, dan semuanya berfungsi dengan baik. Jika Anda membuat model yang tepat, maka programmer masih tidak memperhatikan nomor versi, hanya saja semuanya akan bekerja lebih baik dan menjadi lebih jelas. Alur kerja yang ada hampir tidak akan berubah. Rilis versi baru sangat sederhana. Secara umum, kontrol versi harus dilakukan di pinggir jalan dan tidak menghilangkan perhatian pengembang.

Singkatnya, Anda perlu menambahkan kontrol versi paket, tetapi tidak break go get . Dalam artikel ini, kami menyarankan cara melakukan ini, dan juga menunjukkan prototipe yang dapat Anda coba sekarang, dan yang, saya harap, akan menjadi dasar untuk integrasi yang mungkin go . Saya harap artikel ini akan menjadi awal dari diskusi yang produktif tentang apa yang berhasil dan yang tidak. Berdasarkan diskusi ini, saya akan membuat penyesuaian untuk proposal saya dan prototipe, dan kemudian saya akan mempresentasikan proposal resmi untuk menambahkan fungsi opsional untuk Go 1.11.

Proposal ini mempertahankan semua manfaat dari go get , tetapi menambahkan build yang dapat direproduksi, mendukung kontrol versi semantik, menghilangkan vendorisasi, menghilangkan GOPATH demi alur kerja berbasis proyek, dan memberikan perpindahan yang mulus dari dep dan pendahulunya. Namun, proposal ini masih dalam tahap awal. Jika detailnya tidak benar, kami akan memperbaikinya sebelum pekerjaan masuk ke distribusi Go utama.

Situasi umum

Sebelum memeriksa proposal, mari kita lihat situasi saat ini dan bagaimana kita berakhir di situ. Bagian ini mungkin agak terlalu besar, tetapi sejarah membawa pelajaran penting dan membantu untuk memahami mengapa kita ingin mengubah sesuatu. Jika ini tidak menarik bagi Anda, Anda dapat langsung pergi ke penawaran atau membaca artikel blog yang menyertainya dengan contoh .

Makefile , goinstall dan go get

Pada November 2009, kompiler, tautan, dan beberapa perpustakaan dirilis dengan versi awal Go. Untuk mengkompilasi dan menautkan program, perlu menjalankan 6g dan 6l , dan kami memasukkan sampel makefile dalam kit. Shell gobuild minimal dapat mengkompilasi satu paket dan menulis makefile yang sesuai (dalam kebanyakan kasus). Tidak ada cara yang pasti untuk membagikan kode dengan orang lain. Kami tahu bahwa ini tidak cukup - tetapi kami merilis apa yang kami miliki, berencana untuk mengembangkan sisanya bersama dengan masyarakat.

Pada Februari 2010, kami mengusulkan goinstall , perintah sederhana untuk mengunduh paket dari repositori sistem kontrol versi seperti Bitbucket dan GitHub. Goinstall memperkenalkan konvensi tentang jalur impor yang sekarang diterima secara umum. Tetapi pada saat itu, tidak ada kode yang mengikuti konvensi ini; goinstall pada awalnya hanya bekerja dengan paket yang tidak mengimpor apa pun kecuali perpustakaan standar. Tetapi pengembang dengan cepat pindah ke satu perjanjian yang kita kenal sekarang, dan paket Go yang diterbitkan telah tumbuh menjadi ekosistem holistik.

Goinstall juga memperbaiki Makefiles, dan bersamanya kompleksitas opsi build kustom. Meskipun kadang-kadang merepotkan bahwa pembuat paket tidak dapat menghasilkan kode selama setiap pembuatan, penyederhanaan ini sangat penting bagi pengguna paket: mereka tidak perlu khawatir menginstal seperangkat alat yang sama yang digunakan penulis. Penyederhanaan ini juga penting untuk pengoperasian alat. Makefile adalah resep langkah demi langkah yang diperlukan untuk menyusun paket; dan menerapkan alat lain seperti go vet atau pelengkapan otomatis untuk paket yang sama bisa sangat sulit. Bahkan mendapatkan dependensi dengan benar, untuk membangun kembali paket jika perlu dan hanya jika perlu, jauh lebih rumit dengan Makefile yang sewenang-wenang. Meskipun pada saat itu beberapa orang keberatan bahwa mereka kehilangan fleksibilitas, tetapi melihat ke belakang, menjadi jelas bahwa meninggalkan Makefile adalah langkah yang tepat: manfaatnya jauh lebih besar daripada ketidaknyamanan.

Pada bulan Desember 2011, dalam persiapan untuk Go 1, kami memperkenalkan perintah go , yang menggantikan goinstall dengan go get .

Secara umum, go get diperkenalkan perubahan signifikan: itu memungkinkan pengembang Go untuk bertukar kode sumber dan menggunakan karya masing-masing. Dia juga mengisolasi bagian-bagian dari sistem build di dalam perintah go , sehingga otomatisasi yang signifikan dengan bantuan alat menjadi mungkin. Tapi go get kurang konsep kontrol versi. Pada diskusi pertama tentang goinstall, menjadi jelas: Anda perlu melakukan sesuatu dengan kontrol versi. Sayangnya, tidak jelas apa yang harus dilakukan. Setidaknya kami di tim Go tidak memahami ini dengan jelas. Ketika go get permintaan paket, itu selalu mendapatkan salinan terbaru, mendelegasikan unduhan dan memperbarui operasi ke sistem kontrol versi seperti Git atau Mercurial. "Pekerjaan buta" seperti itu telah menyebabkan setidaknya dua kelemahan signifikan.

Versi dan Stabilitas API

Kelemahan utama yang pertama adalah bahwa tanpa konsep kontrol versi, ia tidak dapat memberi tahu pengguna apa pun tentang perubahan apa yang diharapkan dalam pembaruan ini.

Pada November 2013, versi Go 1.2 menambahkan entri FAQ dengan saran tentang versi (teks tidak berubah ke versi Go 1.10):

Paket untuk penggunaan umum harus menjaga kompatibilitas ke belakang saat berevolusi. Go 1 rekomendasi kompatibilitas relevan di sini: jangan menghapus nama yang diekspor, mendorong penandaan literal majemuk, dan sebagainya. Jika fungsionalitas baru diperlukan, tambahkan nama baru alih-alih mengganti yang lama. Dalam hal perubahan mendasar, buat paket baru dengan jalur impor baru.

Pada bulan Maret 2014, Gustavo Niemeyer meluncurkan gopkg.in dengan kedok "API stabil untuk bahasa Go." Domain ini adalah pengalihan GitHub gopkg.in/yaml.v1 versi yang memungkinkan Anda mengimpor jalur seperti gopkg.in/yaml.v1 dan gopkg.in/yaml.v2 untuk berbagai komit (mungkin di cabang yang berbeda) dari satu repositori Git. Menurut versi semantik, penulis harus, ketika membuat perubahan kritis, merilis versi utama baru. Dengan demikian, versi jalur impor v1 menggantikan yang sebelumnya, dan v2 dapat memberikan API yang sama sekali berbeda.

Pada Agustus 2015, Dave Cheney mengajukan proposal untuk kontrol versi semantik . Selama beberapa bulan ke depan, ini memicu diskusi yang menarik: semua orang tampaknya setuju bahwa penandaan versi semantik adalah ide yang bagus, tetapi tidak ada yang tahu bagaimana alat harus bekerja dengan versi ini.

Argumen apa pun untuk versi semantik pasti akan dikritik dengan mengacu pada hukum Hyrum :

Kontrak API Anda menjadi tidak penting dengan jumlah pengguna yang cukup. Seseorang tergantung pada perilaku sistem yang diamati.

Meskipun hukum Hyrum secara empiris benar, kontrol versi semantik masih merupakan cara yang berguna untuk menghasilkan harapan tentang hubungan antara rilis. Upgrade dari 1.2.3 ke 1.2.4 tidak boleh merusak kode Anda, dan upgrade dari 1.2.3 ke 2.0.0 mungkin sangat baik. Jika kode berhenti bekerja setelah memperbarui ke 1.2.4, maka kemungkinan besar penulis akan menerima laporan bug dan memperbaiki kesalahan dalam versi 1.2.5. Jika kode berhenti bekerja (atau bahkan dikompilasi) setelah memperbarui ke 2.0.0, maka perubahan ini lebih mungkin disengaja dan, karenanya, tidak mungkin ada sesuatu yang akan diperbaiki di 2.0.1.

Saya tidak ingin menyimpulkan dari hukum Hiram bahwa versi semantik tidak mungkin. Sebaliknya, saya percaya bahwa majelis harus digunakan dengan hati-hati, menggunakan versi yang persis sama dari setiap ketergantungan seperti penulis. Artinya, perakitan default harus dapat direproduksi sebaik mungkin.

Majelis penjual dan yang dapat direproduksi

Kelemahan utama kedua dari go get adalah bahwa tanpa konsep kontrol versi, sebuah tim tidak dapat menyediakan dan bahkan mengekspresikan ide membangun yang dapat direproduksi. Anda tidak dapat memastikan bahwa pengguna menyusun versi yang sama dari dependensi kode seperti Anda. Pada November 2013, FAQ berikut ditambahkan ke FAQ untuk Go 1.2:

Jika Anda menggunakan paket eksternal dan takut akan berubah secara tidak terduga, solusi termudah adalah menyalinnya ke repositori lokal (pendekatan ini digunakan oleh Google). Simpan salinan dengan jalur impor baru yang mengidentifikasinya sebagai salinan lokal. Misalnya, Anda dapat menyalin original.com/pkg ke you.com/external/original.com/pkg . Salah satu alat untuk prosedur ini adalah goven Kit Rerik.

Keith Rarik memulai proyek ini pada Maret 2012. Utilitas goven menyalin ketergantungan ke repositori lokal dan memperbarui semua jalur impor untuk mencerminkan lokasi baru. Perubahan kode sumber seperti itu perlu, tetapi tidak menyenangkan. Mereka membuat sulit untuk membandingkan dan memasukkan salinan baru, dan juga memerlukan memperbarui kode yang disalin lainnya menggunakan dependensi ini.

Pada September 2013, Keith memperkenalkan godep , "alat baru untuk memperbaiki dependensi paket." Pencapaian utama dari godep adalah apa yang sekarang kita sebut pembatalan, yaitu menyalin ketergantungan ke proyek tanpa mengubah file sumber, tanpa dukungan langsung untuk alat, melalui konfigurasi GOPATH tertentu.

Pada Oktober 2014, Keith mengusulkan menambahkan dukungan untuk "paket eksternal" ke alat Go sehingga alat lebih memahami proyek menggunakan konvensi ini. Pada saat itu, beberapa utilitas gaya godep sudah muncul. Matt Farina menerbitkan sebuah posting "Bepergian Manajer godep Sea of ​​Go" yang membandingkan godep dengan godep , terutama glide .

Pada bulan April 2015, Dave Cheney memperkenalkan gb , “alat pembangunan berbasis proyek ... dengan pembangunan berulang melalui sumber penjual,” lagi tanpa menulis ulang jalur impor (motivasi lain untuk membuat gb adalah untuk menghindari keharusan menyimpan kode di direktori tertentu di GOPATH yang tidak selalu nyaman).

Musim semi itu, Jason Buberlie memeriksa situasi dengan sistem manajemen paket Go, termasuk beberapa duplikasi upaya dan pekerjaan sia-sia pada utilitas serupa. Surveinya menjelaskan kepada pengembang bahwa dukungan untuk penjual tanpa menulis ulang jalur impor harus ditambahkan ke perintah go . Pada saat yang sama, Daniel Theofanes mulai menyiapkan spesifikasi untuk format file yang menggambarkan asal dan versi kode yang tepat di direktori vendor. Pada Juni 2015, kami menerima proposal Keith sebagai percobaan penjual otomatis di Go 1.5 , yang dimasukkan secara default di Go 1.6. Kami mendorong penulis semua alat penjual untuk bekerja dengan Daniel untuk mengadopsi format file metadata tunggal.

Memperkenalkan konsep vending in Go, alat yang diizinkan seperti vet untuk menganalisis program secara lebih kompeten, dan hari ini telah digunakan oleh selusin atau dua manajer paket atau alat penjual. Di sisi lain, karena setiap orang memiliki format metadata yang berbeda, mereka tidak berinteraksi dan tidak dapat dengan mudah bertukar informasi ketergantungan.

Lebih mendasar lagi, penjual otomatis adalah solusi yang tidak lengkap untuk masalah kontrol versi. Ini hanya memberikan kemampuan reproduksi perakitan, tetapi tidak membantu untuk memahami versi paket dan memutuskan mana yang akan digunakan. Manajer paket seperti glide dan dep secara implisit menambahkan konsep kontrol versi ke Go, mengatur direktori vendor dengan cara tertentu. Akibatnya, banyak alat di ekosistem Go mungkin tidak bisa mendapatkan informasi versi yang benar. Jelas bahwa Go membutuhkan dukungan langsung untuk versi paket.

Eksperimen Manajemen Paket Resmi

Di GopherCon 2016 pada Hari Peretasan (sekarang Hari Komunitas), sekelompok aktivis Go berkumpul untuk membahas secara luas masalah manajemen paket . Salah satu hasilnya adalah pembentukan komite dan kelompok penasihat untuk melakukan berbagai kegiatan dengan tujuan menciptakan alat manajemen paket baru . Idenya adalah untuk memiliki alat terpadu menggantikan yang sudah ada, meskipun masih akan diterapkan di luar toolkit langsung Go menggunakan katalog vendor. Panitia termasuk Andrew Gerrand, Ed Muller, Jesse Frazel dan Sam Boyer, yang dipimpin oleh Peter Burgon. Mereka menyiapkan spesifikasi rancangan , dan kemudian Sam dan asistennya mengimplementasikan dep . Untuk memahami situasi umum, lihat artikel Sam di Februari 2016, “Jadi Anda Ingin Menulis Manajer Paket,” posting Desember 2016-nya “Go Dependency Management Saga,” dan pidatonya di Juli 2017 di GopherCon, “Era Baru Manajemen Paket di Pergi . "

Dep melakukan banyak tugas: ini merupakan peningkatan penting dari praktik saat ini. Ini adalah langkah penting menuju solusi masa depan, dan pada saat yang sama sebuah eksperimen - kami menyebutnya "eksperimen resmi" - yang membantu kami lebih memahami kebutuhan pengembang. Tetapi dep bukan prototipe langsung dari kemungkinan integrasi perintah go dalam versi paket. Ini adalah cara yang kuat, fleksibel, hampir universal untuk mengeksplorasi ruang keputusan desain. Ini mirip dengan makefile yang kami lawan di awal. Tetapi segera setelah kami lebih memahami ruang keputusan desain dan dapat mempersempitnya ke beberapa fungsi utama yang harus didukung, ini akan membantu ekosistem Go untuk menghapus fungsi-fungsi lain, mengurangi ekspresif, dan mengadopsi konvensi mengikat yang membuat basis kode Go lebih konsisten dan lebih mudah untuk dipahami.

Artikel ini adalah awal dari langkah selanjutnya setelah dep : prototipe pertama dari integrasi akhir dengan perintah go , batch yang setara dengan goinstall . Prototipe adalah perintah terpisah yang kami sebut vgo : pengganti go dengan dukungan untuk versi paket. Ini adalah eksperimen baru, dan kita akan lihat apa yang terjadi. Seperti pada pengumuman goinstall , beberapa proyek dan kode sekarang kompatibel dengan vgo , sementara yang lain membutuhkan perubahan. Kami akan menghapus beberapa kontrol dan ekspresi, sama seperti makefile dihapus untuk menyederhanakan sistem dan menghilangkan kerumitan bagi pengguna. Yang terpenting, kami mencari pelopor yang akan membantu bereksperimen dengan vgo untuk mendapatkan ulasan sebanyak mungkin.

Memulai percobaan dengan vgo tidak berarti menghentikan dukungan dep : itu akan tetap tersedia sampai kami mencapai integrasi penuh dan terbuka dengan go . Kami juga akan mencoba membuat transisi terakhir dari dep ke integrasi dengan go semulus mungkin, dalam bentuk apa pun integrasi ini terjadi. Proyek-proyek yang belum dikonversi ke dep masih dapat mengambil manfaat dari konversi ini (perhatikan bahwa godep dan glide menghentikan pengembangan aktif dan mendorong migrasi ke dep). Mungkin beberapa proyek akan ingin beralih langsung ke vgo jika ini memenuhi kebutuhan mereka.

Tawarkan

Proposal untuk menambahkan kontrol versi ke perintah go terdiri dari empat langkah. Pertama, terima aturan kompatibilitas impor , yang ditunjukkan oleh FAQ dan gopkg.in: versi yang lebih baru dari paket dengan jalur impor yang ditentukan harus kompatibel dengan versi yang lebih lama. Kedua, mengadopsi algoritma baru yang sederhana, yang dikenal sebagai memilih versi minimum untuk menentukan versi paket mana yang digunakan dalam perakitan ini. Ketiga, perkenalkan konsep modul Go: kelompok paket yang diversi secara keseluruhan dan nyatakan persyaratan minimum yang harus dipenuhi oleh dependensinya. Keempat, tentukan bagaimana mengintegrasikan semua ini ke dalam perintah go ada sehingga alur kerja dasar tidak berubah secara signifikan mulai hari ini. Di sisa artikel ini, kita melihat masing-masing langkah ini. Mereka dibahas lebih rinci dalam artikel blog lainnya .

Aturan Kompatibilitas Impor

Masalah utama dengan sistem manajemen paket adalah upaya untuk menyelesaikan ketidakcocokan. Sebagai contoh, sebagian besar sistem mengizinkan paket B untuk menyatakan bahwa ia membutuhkan paket D versi 6 atau lebih baru, dan kemudian mengizinkan paket C untuk menyatakan bahwa ia membutuhkan D versi 2, 3, atau 4, tetapi bukan versi 5 atau lebih baru. Jadi, jika Anda ingin menggunakan B dan C dalam paket Anda, maka Anda kurang beruntung: Anda tidak dapat memilih versi D yang memenuhi kedua kondisi, dan Anda tidak dapat melakukan apa pun.

Alih-alih sebuah sistem yang mau tidak mau menghalangi perakitan program besar, proposal kami memperkenalkan aturan kompatibilitas impor untuk pembuat paket:

Jika paket lama dan baru memiliki jalur impor yang sama, paket baru harus kompatibel dengan paket lama.

Aturan ini mengulangi FAQ yang disebutkan sebelumnya. Teks itu berakhir dengan kata-kata: "Jika terjadi perubahan radikal, buat paket baru dengan jalur impor baru."Hari ini, untuk perubahan besar seperti itu, pengembang mengandalkan kontrol versi semantik, jadi kami mengintegrasikannya ke dalam proposal kami. Secara khusus, jumlah versi utama kedua dan selanjutnya dapat langsung dimasukkan dalam jalur:

 import "github.com/go-yaml/yaml/v2" 

Dalam kontrol versi semantik, versi 2.0.0 berarti perubahan radikal, sehingga paket baru dibuat dengan jalur impor baru. Karena setiap versi utama memiliki jalur impor yang berbeda, Go executable tertentu dapat berisi salah satu versi utama. Ini diharapkan dan diinginkan. Sistem seperti itu mendukung perakitan program dan memungkinkan bagian-bagian dari program yang sangat besar untuk meningkatkan secara independen dari v1 ke v2 secara independen.

Kepatuhan penulis terhadap aturan kompatibilitas impor menghilangkan upaya untuk menyelesaikan ketidaksesuaian dengan menyederhanakan secara keseluruhan sistem keseluruhan dan mengurangi fragmentasi ekosistem paket. Tentu saja, dalam praktiknya, terlepas dari semua upaya penulis, pembaruan dalam versi utama yang sama terkadang merusak paket pengguna. Karena itu, Anda tidak perlu memperbarui terlalu sering. Ini membawa kita ke langkah selanjutnya.

Pilihan Versi Minimum

, dep cargo , . , . -, « » - , - . , - , , , . -, , , «, X», X .

Proposal kami menggunakan pendekatan yang berbeda, yang saya sebut pemilihan versi minimum . Secara default, versi terlama yang diizinkan dari setiap paket digunakan. Keputusan ini tidak akan berubah besok, karena tidak mungkin untuk menerbitkan versi yang lebih lama. Lebih baik lagi, pengelola paket sepele untuk menentukan versi mana yang akan digunakan. Saya menyebutnya pilihan versi minimum, karena nomor versi yang dipilih minimal, dan juga karena sistem secara keseluruhan mungkin juga minimal, menghindari hampir semua kompleksitas sistem yang ada.

Memilih versi minimum memungkinkan modul untuk menentukan hanya persyaratan minimum untuk dependensi. Ini jelas, jawaban unik untuk pembaruan dan operasi downgrade, dan operasi ini sangat efektif. Prinsip ini memungkinkan penulis seluruh modul untuk menunjukkan versi dependensi yang ingin dikecualikannya, atau untuk mengindikasikan penggantian dependensi spesifik dengan fork-nya, yang terletak di penyimpanan lokal atau diterbitkan sebagai modul terpisah. Pengecualian dan penggantian ini tidak berlaku ketika modul dibangun sebagai ketergantungan dari beberapa modul lainnya. Ini memberi pengguna kendali penuh atas bagaimana program mereka dirakit, tetapi tidak pada orang asing.

Memilih versi minimum menyediakan rakitan yang dapat direproduksi secara default tanpa file kunci.

Kompatibilitas impor adalah kunci untuk membuat versi minimum mudah dipilih. Pengguna tidak bisa lagi mengatakan "tidak, ini versi yang terlalu baru", mereka hanya bisa mengatakan "tidak, ini terlalu lama". Dalam hal ini, solusinya jelas: gunakan versi (minimum) yang lebih baru. Dan versi yang lebih baru dengan konvensi adalah pengganti yang dapat diterima untuk yang lebih lama.

Mendefinisikan Modul Go

Modul Go adalah kumpulan paket dengan awalan jalur impor umum yang dikenal sebagai jalur modul. Modul adalah unit kontrol versi, dan versi ditulis sebagai string semantik. Saat mengembangkan dengan Git, pengembang mendefinisikan versi semantik baru dari modul dengan menambahkan tag ke repositori Git dari modul. Meskipun Anda sangat disarankan untuk menentukan versi semantik, tautan ke komit tertentu juga didukung.

Dalam file baru, go.modmodul mendefinisikan persyaratan versi minimum untuk modul lain yang bergantung padanya. Sebagai contoh, ini adalah file sederhana go.mod:

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 ) 

File ini mendefinisikan modul yang diidentifikasi oleh path rsc.io/hello, dan itu tergantung pada dua modul lainnya: golang.org/x/textdan rsc.io/quote. Perakitan modul itu sendiri akan selalu menggunakan versi tertentu dari dependensi yang diperlukan yang tercantum dalam file go.mod. Sebagai bagian dari rakitan yang lebih besar, ia hanya dapat menggunakan versi yang lebih baru jika beberapa bagian lain dari rakitan memerlukannya.

Penulis menandai rilis mereka dengan versi semantik, dan vgomerekomendasikan menggunakan versi yang ditandai, daripada melakukan sewenang-wenang. Modul rsc.io/quoteyang disertakan github.com/rsc/quotememiliki versi yang ditandai, termasuk 1.5.2. Namun, modul belum memiliki golang.org/x/textversi yang ditandai. Untuk menyebutkan komit yang tidak ditandai, versi pseudo v0.0.0-yyyymmddhhmmss-commitmendefinisikan komit tertentu pada tanggal tertentu. Dalam versi semantik, baris ini sesuai dengan prerelease v0.0.0 dengan identifier yyyymmddhhhmmss-commit . Aturan semantik prioritas versi mengakui pra-rilis seperti lebih awal dari versi v0.0.0, dan melakukan perbandingan string. Urutan tanggal dalam versi pseudo memastikan bahwa perbandingan string cocok dengan perbandingan tanggal.

Selain persyaratan ini, file go.moddapat menunjukkan pengecualian dan penggantian yang disebutkan di bagian sebelumnya, tetapi sekali lagi mereka hanya berlaku ketika membangun modul yang terisolasi, dan tidak ketika membangun sebagai bagian dari program yang lebih besar. Semua ini ditunjukkan dalam contoh .

Goinstalldan tuago getalat kontrol versi, seperti gitdan hg, dipanggil untuk mengunduh kode , yang menyebabkan banyak masalah, termasuk fragmentasi. Misalnya, pengguna tanpa bzrtidak dapat mengunduh kode dari gudang Bazaar. Tidak seperti sistem ini, modul Go selalu dikeluarkan melalui HTTP dalam bentuk arsip zip. Sebelumnya, ada go gettim khusus untuk situs hosting kode populer. Sekarang mereka memiliki vgoprosedur API khusus untuk menerima arsip dari situs-situs ini.

Penyajian modul yang seragam dalam bentuk arsip zip memungkinkan penerapan protokol dan server proxy untuk memuat modul. Perusahaan dan pengguna perorangan memiliki alasan berbeda untuk memulai server proxy tersebut, termasuk keamanan dan keinginan untuk bekerja dengan salinan dalam cache jika ada dokumen asli dihapus. Dengan adanya proksi, untuk memastikan aksesibilitas dan go.moduntuk menentukan kode mana yang akan digunakan, direktori vendor tidak lagi diperlukan.

Tim go

Untuk bekerja dengan modul, perintah goharus diperbarui. Salah satu perubahan utama adalah bahwa membangun biasa perintah seperti go build, go install, go rundan go test, akan memungkinkan untuk dependensi baru menuntut. Untuk digunakan golang.org/x/textdalam modul yang sama sekali baru, tambahkan saja impor ke kode sumber Go dan build.

Tetapi perubahan yang paling signifikan adalah perpisahan dengan GOPATH sebagai tempat untuk menulis kode. Karena file go.modmenyertakan path lengkap ke modul, dan juga menentukan versi setiap dependensi yang digunakan, direktori dengan file go.modmenandai akar dari pohon direktori, yang berfungsi sebagai ruang kerja otonom, secara terpisah dari direktori lain seperti itu. Sekarang Anda hanya melakukan git clone,cd, dan mulai menulis. Di mana saja. Tidak ada gopath

Apa selanjutnya

Saya juga menerbitkan Tur Pembuatan Versi dengan demo cara menggunakannya vgo. Artikel itu memberi tahu Anda cara mengunduh dan mulai menggunakan hari ini vgo. Informasi lain di artikel lain . Saya akan senang berkomentar.

Silakan coba vgo . Mulai memberi tag versi dalam repositori dengan tag semantik. Buat file go.mod. Catatan bahwa jika file kosong dalam repositori go.mod, tetapi ada dep, glide, glock, godep, godeps, govend, govendoratau file konfigurasi gvt, kemudian vgomenggunakan mereka untuk mengisi file go.mod.

Saya senang bahwa Go mengambil langkah yang lama tertunda ini dalam mendukung versi. Beberapa masalah paling umum yang dihadapi oleh pengembang Go adalah kurangnya build yang dapat direproduksi, pengabaian tag rilis yang lengkap dari luar go get, ketidakmampuan GOPATH untuk mengenali berbagai versi paket, dan ketidakmampuan untuk bekerja di direktori di luar GOPATH. Desain yang ditawarkan di sini menghilangkan semua masalah ini dan banyak lagi.

Tapi saya mungkin salah dalam beberapa detail. Saya harap pembaca dapat membantu memperbaikinya dengan menguji prototipe vgodan berpartisipasi dalam diskusi yang produktif. Saya ingin Go 1.11 datang dengan dukungan awal untuk modul Go, sebagai semacam demo, dan kemudian Go 1.12 keluar dengan dukungan resmi. Dalam versi yang lebih baru, kami akan menghapus dukungan untuk yang lama, bukan versigo get. Tetapi ini adalah rencana yang agresif, dan jika untuk fungsionalitas yang benar Anda perlu menunggu rilis nanti, biarlah.

Saya sangat prihatin dengan transisi dari go getalat penjual lama dan tak terhitung ke sistem modular baru. Proses ini sama pentingnya bagi saya dengan fungsi yang tepat. Jika transisi yang berhasil berarti menunggu rilis nanti, maka lakukanlah lagi.