Go: cmd/go: tambahkan dukungan versi paket ke Go toolchain

Pertanyaan yang Sering Diajukan

Komentar masalah ini menjawab pertanyaan yang paling sering diajukan, baik dari diskusi di bawah ini atau dari diskusi lain. Pertanyaan lain dari diskusi ada di komentar edisi berikutnya.

Mengapa proposal tidak "menggunakan Dep "?

Pada awal perjalanan yang mengarah pada proposal ini, hampir dua tahun yang lalu, kita semua percaya bahwa jawabannya adalah mengikuti pendekatan versi paket yang dicontohkan oleh Ruby's Bundler dan kemudian Rust's Cargo: tagged semantic version, a hand-edited dependency constraint file dikenal sebagai manifes, deskripsi ketergantungan transitif yang dihasilkan mesin terpisah yang dikenal sebagai file kunci, pemecah versi untuk menghitung file kunci yang memenuhi manifes, dan repositori sebagai unit pembuatan versi. Dep mengikuti rencana kasar ini hampir persis dan pada awalnya dimaksudkan sebagai model untuk integrasi perintah go. Namun, semakin saya memahami detail pendekatan Bundler/Cargo/Dep dan apa artinya bagi Go, terutama yang dibangun ke dalam perintah go, dan semakin saya mendiskusikan detail tersebut dengan orang lain di tim Go, beberapa detailnya tampaknya semakin tidak cocok untuk Go. Proposal menyesuaikan detail tersebut dengan harapan mengirimkan sistem yang lebih mudah dipahami dan digunakan oleh pengembang. Lihat bagian alasan proposal untuk mengetahui lebih lanjut tentang detail spesifik yang ingin kami ubah, dan juga entri blog yang mengumumkan proposal .

Mengapa nomor versi utama harus muncul di jalur impor?

Untuk mengikuti aturan kompatibilitas impor , yang secara dramatis menyederhanakan sisa sistem. Lihat juga posting blog yang mengumumkan proposal , yang berbicara lebih banyak tentang motivasi dan pembenaran untuk aturan kompatibilitas impor.

Mengapa versi utama v0, v1 dihilangkan dari jalur impor?

v1 dihilangkan dari jalur impor karena dua alasan. Pertama, banyak pengembang akan membuat paket yang tidak pernah membuat perubahan besar setelah mencapai v1, yang merupakan sesuatu yang kami dorong sejak awal. Kami tidak percaya semua pengembang tersebut harus dipaksa untuk memiliki v1 eksplisit ketika mereka mungkin tidak berniat untuk merilis v2. v1 menjadi hanya kebisingan. Jika pengembang tersebut akhirnya membuat v2, presisi ekstra akan muncul, untuk membedakan dari default, v1. Ada argumen bagus tentang stabilitas yang terlihat untuk menempatkan v1 di mana-mana, dan jika kami merancang sistem dari awal, mungkin itu akan membuatnya menjadi panggilan yang dekat. Tetapi bobot kode yang ada sangat membantu untuk menghilangkan v1.

v0 dihilangkan dari jalur impor karena - menurut semver - tidak ada jaminan kompatibilitas sama sekali untuk versi tersebut. Memerlukan elemen v0 eksplisit tidak akan banyak membantu memastikan kompatibilitas; Anda harus mengatakan v0.1.2 agar benar-benar tepat, memperbarui semua jalur impor pada setiap pembaruan perpustakaan. Itu sepertinya berlebihan. Sebaliknya, kami berharap pengembang hanya akan melihat daftar modul yang mereka andalkan dan berhati-hati dengan versi v0.xy yang mereka temukan.

Ini memiliki efek tidak membedakan v0 dari v1 di jalur impor, tetapi biasanya v0 adalah urutan perubahan pemutusan yang mengarah ke v1, jadi masuk akal untuk memperlakukan v1 sebagai langkah terakhir dalam urutan pemutusan itu, bukan sesuatu yang perlu dibedakan dari v0 . Seperti yang dikatakan @Merovius (https://github.com/golang/go/issues/24301#issuecomment-376213693):

Dengan menggunakan v0.x, Anda menerima bahwa v0.(x+1) mungkin memaksa Anda untuk memperbaiki kode Anda. Mengapa menjadi masalah jika v0.(x+1) disebut v1.0?

Terakhir, menghilangkan versi utama v0 dan v1 adalah wajib - bukan opsional - sehingga ada jalur impor kanonik tunggal untuk setiap paket.

Mengapa saya harus membuat cabang baru untuk v2 alih-alih terus mengerjakan master?

Anda tidak perlu membuat cabang baru. Sayangnya, posting modul vgo memberikan kesan itu dalam diskusi tentang tata letak repositori "cabang utama". Tetapi vgo tidak peduli dengan cabang. Itu hanya mencari tag dan menyelesaikan komit spesifik mana yang mereka tunjuk. Jika Anda mengembangkan v1 pada master, Anda memutuskan bahwa Anda benar-benar selesai dengan v1, dan Anda ingin mulai membuat komitmen v2 pada master, itu bagus: mulai menandai master dengan tag v2.xy. Namun perhatikan bahwa beberapa pengguna Anda akan tetap menggunakan v1, dan terkadang Anda mungkin ingin melakukan perbaikan bug minor v1. Anda mungkin setidaknya ingin melakukan fork cabang v1 baru untuk pekerjaan itu pada titik di mana Anda mulai menggunakan master untuk v2.

Bukankah pemilihan versi minimal akan membuat pengembang tidak mendapatkan pembaruan penting?

Ini adalah ketakutan yang umum, tetapi saya benar-benar berpikir jika sesuatu yang sebaliknya akan terjadi. Mengutip bagian "Kecepatan Peningkatan" https://research.swtch.com/vgo-mvs :

Mengingat bahwa pemilihan versi minimal membutuhkan versi minimum yang diizinkan dari setiap ketergantungan, mudah untuk berpikir bahwa ini akan mengarah pada penggunaan salinan paket yang sangat lama, yang pada gilirannya dapat menyebabkan bug atau masalah keamanan yang tidak perlu. Namun, dalam praktiknya, saya pikir sebaliknya akan terjadi, karena versi minimum yang diizinkan adalah maksimum dari semua batasan, jadi satu-satunya tuas kontrol yang tersedia untuk semua modul dalam sebuah build adalah kemampuan untuk memaksa penggunaan versi yang lebih baru. ketergantungan daripada yang akan digunakan. Saya berharap bahwa pengguna dengan pemilihan versi minimal akan mendapatkan program yang hampir sama mutakhirnya dengan teman-teman mereka yang menggunakan sistem yang lebih agresif seperti Cargo.

Misalnya, Anda sedang menulis sebuah program yang bergantung pada beberapa modul lain, yang semuanya bergantung pada beberapa modul yang sangat umum, seperti gopkg.in/yaml.v2. Build program Anda akan menggunakan versi YAML terbaru di antara versi yang diminta oleh modul Anda dan beberapa dependensi. Bahkan hanya satu dependensi yang teliti dapat memaksa build Anda memperbarui banyak dependensi lainnya. Ini adalah kebalikan dari masalah klien Kubernetes Go yang saya sebutkan sebelumnya.

Jika ada, pemilihan versi minimal malah akan mengalami masalah sebaliknya, bahwa jawaban "maks dari minimum" ini berfungsi sebagai ratchet yang memaksa dependensi maju terlalu cepat. Tapi saya pikir dalam praktiknya dependensi akan bergerak maju dengan kecepatan yang tepat, yang akhirnya menjadi jumlah yang tepat lebih lambat daripada Cargo dan teman-teman.

Dengan "jumlah yang tepat lebih lambat" saya mengacu pada properti utama yang pemutakhiran hanya terjadi ketika Anda memintanya, bukan ketika Anda belum melakukannya. Itu berarti bahwa kode hanya berubah (dengan cara yang berpotensi tidak terduga dan merusak) ketika Anda mengharapkan hal itu terjadi dan siap untuk mengujinya, men-debugnya, dan seterusnya.

Lihat juga tanggapan https://github.com/golang/go/issues/24301#issuecomment -375992900 oleh @Merovius.

Jika $GOPATH tidak digunakan lagi, di mana kode yang diunduh tinggal?

Kode yang Anda periksa dan kerjakan dan modifikasi dapat disimpan di mana saja di sistem file Anda, sama seperti pada dasarnya setiap alat pengembang lainnya.

Vgo memang membutuhkan ruang untuk menyimpan kode sumber yang diunduh dan menginstal binari, dan untuk itu ia masih menggunakan $GOPATH, yang pada Go 1.9 default ke $HOME/go. Jadi pengembang tidak perlu mengatur $GOPATH kecuali mereka ingin file-file ini berada di direktori yang berbeda. Untuk mengubah hanya lokasi pemasangan biner, mereka dapat mengatur $GOBIN (seperti biasa).

Mengapa Anda memperkenalkan komentar // import ?

Tidak. Itu adalah konvensi yang sudah ada sebelumnya . Inti dari contoh itu dalam tur adalah untuk menunjukkan bagaimana go.mod dapat menyimpulkan jalur modul yang benar dari komentar impor, jika ada. Setelah semua proyek menggunakan file go.mod , komentar impor akan sepenuhnya berlebihan dan mungkin tidak digunakan lagi.

Ringkasan Diskusi (terakhir diperbarui 25-04-2017)

Komentar masalah ini berisi ringkasan diskusi di bawah ini.

Bagaimana kita bisa menangani migrasi?

[ https://github.com/golang/go/issues/24301#issuecomment -374739116 oleh @ChrisHines.]

Tanggapan https://github.com/golang/go/issues/24301#issuecomment -377529520 oleh @rsc. Proposal asli mengasumsikan migrasi ditangani oleh penulis yang pindah ke subdirektori ketika kompatibilitas penting bagi mereka, tetapi tentu saja motivasi itu salah. Kompatibilitas paling penting bagi pengguna, yang memiliki pengaruh kecil pada perpindahan penulis. Dan itu tidak membantu versi yang lebih lama. Komentar tertaut, sekarang juga #25069, mengusulkan perubahan minimal ke "go build" lama untuk dapat menggunakan dan membangun kode modul-sadar.

Bagaimana kita bisa menangani pendaftaran singleton?

[ https://github.com/golang/go/issues/24301#issuecomment -374791885 oleh @jimmyfrasche.]

Tanggapan https://github.com/golang/go/issues/24301#issuecomment -377527249 oleh @rsc. Tabrakan pendaftaran tunggal (seperti http.Handle dari jalur yang sama) antara modul yang sama sekali berbeda tidak terpengaruh oleh proposal. Untuk tabrakan antara versi utama yang berbeda dari satu modul, penulis dapat menulis versi utama yang berbeda yang diharapkan untuk dikoordinasikan, biasanya dengan membuat panggilan v1 ke v2, dan kemudian menggunakan siklus persyaratan untuk memastikan v2 tidak digunakan dengan v1 lama yang tidak tidak tahu tentang koordinasi.

Bagaimana seharusnya kita menginstal perintah berversi?

[ https://github.com/golang/go/issues/24301#issuecomment -375106068 oleh @leonklingele.]

Tanggapan https://github.com/golang/go/issues/24301#issuecomment -377417565 oleh @rsc. Singkatnya, gunakan go get. Kami masih menggunakan $GOPATH/bin untuk lokasi pemasangan. Ingat bahwa $GOPATH sekarang default ke $HOME/go, jadi perintah akan berakhir di $HOME/go/bin, dan $GOBIN dapat menimpanya.

Mengapa v0, v1 dihilangkan di jalur impor? Mengapa yang lain harus muncul? Mengapa v0, v1 tidak pernah muncul?

[ https://github.com/golang/go/issues/24301#issuecomment -374818326 oleh @justinian.]
[ https://github.com/golang/go/issues/24301#issuecomment -374831822 oleh @jayschwa.]
[ https://github.com/golang/go/issues/24301#issuecomment -375437150 oleh @mrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -376093912 oleh @mrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -376135447 oleh @kaikuehne.]
[ https://github.com/golang/go/issues/24301#issuecomment -376141888 oleh @kaikuehne.]
[ https://github.com/golang/go/issues/24301#issuecomment -376213693 oleh @Merovius.]
[ https://github.com/golang/go/issues/24301#issuecomment -376247926 oleh @kaikuehne.]

Ditambahkan ke FAQ di atas.

Mengapa file zip disebutkan dalam proposal?

[ https://github.com/golang/go/issues/24301#issuecomment -374839409 oleh @nightlyone.]

Ekosistem akan mendapat manfaat dari mendefinisikan format pertukaran yang konkret. Itu akan mengaktifkan proxy dan perkakas lainnya. Pada saat yang sama, kami mengabaikan penggunaan kontrol versi secara langsung (lihat alasan di atas posting ini ). Kedua motivasi ini menggambarkan format tertentu. Sebagian besar pengembang tidak perlu memikirkan file zip sama sekali; tidak ada pengembang yang perlu melihat ke dalamnya, kecuali mereka sedang membangun sesuatu seperti godoc.org.

Lihat juga #24057 tentang zip vs tar.

Tidakkah menempatkan versi utama di jalur impor melanggar KERING?

[ https://github.com/golang/go/issues/24301#issuecomment -374831822 oleh @jayschwa.]

Tidak, karena semantik impor seharusnya dapat dimengerti tanpa mengacu pada file go.mod. File go.mod hanya menentukan detail yang lebih halus. Lihat paruh kedua bagian versi impor semantik dari proposal , mulai dari kutipan blok.

Juga, jika Anda KERING terlalu banyak, Anda akan berakhir dengan sistem yang rapuh. Redundansi bisa menjadi hal yang baik. Jadi "melanggar [ing] KERING" - artinya, pengulangan yang terbatas - tidak selalu buruk. Misalnya kita meletakkan klausa paket di setiap file .go di direktori, bukan hanya satu. Itu menangkap kesalahan jujur ​​sejak awal dan kemudian berubah menjadi cara mudah untuk membedakan paket pengujian eksternal (paket x vs paket x_test). Ada keseimbangan yang harus dicapai.

Zona waktu mana yang digunakan untuk stempel waktu dalam versi semu?

[ https://github.com/golang/go/issues/24301#issuecomment -374882685 oleh @tpng.]

UTC. Perhatikan juga bahwa Anda tidak perlu mengetikkan versi semu sendiri. Anda dapat mengetikkan hash git commit (atau awalan hash) dan vgo akan menghitung dan mengganti versi semu yang sesuai.

Akankah vgo mengatasi dependensi non-Go, seperti C atau buffer protokol? Kode yang dihasilkan?

[ https://github.com/golang/go/issues/24301#issuecomment -374907338 oleh @AlexRouSg.]
[ https://github.com/golang/go/issues/24301#issuecomment -376606788 oleh @stevvooe.]
[ https://github.com/golang/go/issues/24301#issuecomment -377186949 oleh @nim-nim.]

Pengembangan Non-Go terus menjadi non-tujuan dari perintah go , jadi tidak akan ada dukungan untuk mengelola pustaka C dan semacamnya, juga tidak akan ada dukungan eksplisit untuk buffering protokol.

Meskipun demikian, kami tentu memahami bahwa menggunakan buffering protokol dengan Go terlalu sulit, dan kami ingin agar hal itu ditangani secara terpisah.

Untuk kode yang dihasilkan secara lebih umum, sistem pembangunan lintas bahasa yang sebenarnya adalah jawabannya, khususnya karena kami tidak ingin setiap pengguna harus menginstal generator yang tepat. Lebih baik bagi penulis untuk menjalankan generator dan memeriksa hasilnya.

Bukankah pemilihan versi minimal akan membuat pengembang tidak mendapatkan pembaruan penting?

[ https://github.com/golang/go/issues/24301#issuecomment -375090551 oleh @TocarIP.]
[ https://github.com/golang/go/issues/24301#issuecomment -375985244 oleh @nim-nim.]
[ https://github.com/golang/go/issues/24301#issuecomment -375992900 oleh @Merovius.]

Ditambahkan ke FAQ.

### Dapatkah saya menggunakan master untuk mengembangkan v1 dan kemudian menggunakannya kembali untuk mengembangkan v2?

[ https://github.com/golang/go/issues/24301#issuecomment -375248753 oleh @mrkanister.]
[ https://github.com/golang/go/issues/24301#issuecomment -375989173 oleh @aarondl.]

Ya. Ditambahkan ke FAQ.

Apa timeline untuk ini?

[ https://github.com/golang/go/issues/24301#issuecomment -375415904 oleh @flibustenet.]

Tanggapan di https://github.com/golang/go/issues/24301#issuecomment -377413777 oleh @rsc. Singkatnya, tujuannya adalah untuk mendapatkan "pratinjau teknologi" di Go 1.11; pekerjaan dapat berlanjut beberapa minggu ke dalam pembekuan tetapi tidak lebih jauh. Mungkin jangan mengirim PR menambahkan go.mod ke setiap perpustakaan yang dapat Anda temukan sampai proposal ditandai diterima dan salinan pengembangan cmd/go telah diperbarui.

Bagaimana saya bisa membuat perubahan keamanan yang tidak kompatibel?

[ https://github.com/golang/go/issues/24301#issuecomment -376236546 oleh @buro9.]

Tanggapan di https://github.com/golang/go/issues/24301#issuecomment -377415652 oleh @rsc. Singkatnya, pedoman kompatibilitas Go 1 mengizinkan perubahan yang melanggar demi alasan keamanan untuk menghindari menabrak versi utama, tetapi selalu yang terbaik untuk melakukannya dengan cara yang membuat kode yang ada berfungsi semaksimal mungkin. Misalnya, jangan hapus fungsi. Sebaliknya, buat fungsi panik atau log. Fatal hanya jika dipanggil dengan tidak benar.

Jika satu repo menyimpan modul yang berbeda di subdirektori (misalnya, v2, v3, v4), dapatkah vgo mencampur dan mencocokkan dari komit yang berbeda?

[ https://github.com/golang/go/issues/24301#issuecomment -376266648 oleh @jimmyfrasche.]
[ https://github.com/golang/go/issues/24301#issuecomment -376270750 oleh @AlexRouSg.]

Ya. Ini memperlakukan setiap tag versi sebagai hanya sesuai dengan satu subpohon dari keseluruhan repositori, dan dapat menggunakan tag yang berbeda (dan karena itu komit yang berbeda) untuk setiap keputusan.

Bagaimana jika proyek menyalahgunakan semver? Haruskah kita mengizinkan versi minor di jalur impor?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 oleh @pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376645212 oleh @powerman.]
[ https://github.com/golang/go/issues/24301#issuecomment -376650153 oleh @pbx0.]
[ https://github.com/golang/go/issues/24301#issuecomment -376660236 oleh @powerman.]

Seperti yang dicatat oleh @powerman , kami pasti perlu menyediakan pemeriksa konsistensi API sehingga proyek setidaknya dapat diberi tahu ketika mereka akan merilis perubahan yang jelas-jelas melanggar.

Bisakah Anda menentukan apakah Anda memiliki lebih dari satu paket dalam satu build?

[ https://github.com/golang/go/issues/24301#issuecomment -376640804 oleh @pbx0.]

Hal termudah untuk dilakukan adalah menggunakan goversion -m pada biner yang dihasilkan. Kita harus membuat opsi go untuk menunjukkan hal yang sama tanpa membangun biner.

Kekhawatiran tentang ketergantungan vgo pada proxy vs vendor, terutama open source vs perusahaan.

[ https://github.com/golang/go/issues/24301#issuecomment -376925845 oleh @joeshaw.]
[ https://github.com/golang/go/issues/24301#issuecomment -376936614 oleh @kardianos.]
[ https://github.com/golang/go/issues/24301#issuecomment -376947621 oleh @Merovius.]
[ https://github.com/golang/go/issues/24301#issuecomment -376979054 oleh @joeshaw.]
[ https://github.com/golang/go/issues/24301#issuecomment -376988873 oleh @jamiethermo.]
[ https://github.com/golang/go/issues/24301#issuecomment -377134575 oleh @Merovius.]

Tanggapan: [ https://github.com/golang/go/issues/24301#issuecomment -377411175 oleh @rsc.] Proxy dan vendor keduanya akan didukung. Proxy sangat penting untuk perusahaan, dan vendor sangat penting untuk open source. Kami juga ingin membangun jaringan cermin yang andal, tetapi hanya sekali vgo menjadi go.

Kekhawatiran tentang protobuild tergantung pada semantik GOPATH.

[ https://github.com/golang/go/issues/24301#issuecomment -377601170 oleh @stevvooe.]

Tanggapan [ https://github.com/golang/go/issues/24301#issuecomment -377602765 oleh @rsc] meminta detail lebih lanjut dalam masalah baru, tetapi masalah itu tampaknya belum diajukan.

Saran untuk menambahkan tag vgo-v1-lock khusus.

[ https://github.com/golang/go/issues/24301#issuecomment -377662150 oleh @kybin.]

Tampaknya menarik pada awalnya tetapi mengarah ke kasus-kasus khusus yang mungkin tidak layak untuk diambil. Tanggapan lengkap di https://github.com/golang/go/issues/24301#issuecomment -384344659.

Bagaimana cara menambal ketergantungan yang dalam tanpa vendoring?

[ https://github.com/golang/go/issues/24301#issuecomment -378255833 oleh @chirino.]

Tanggapan [ https://github.com/golang/go/issues/24301#issuecomment -378261916 oleh @kardianos.] Dengan menggunakan perintah replace.

Apa yang akan kita lakukan tentang perubahan nama modul?

[ https://github.com/golang/go/issues/24301#issuecomment -379020339 oleh @jimmyfrasche.]

Tanggapan [ https://github.com/golang/go/issues/24301#issuecomment -379307176 oleh @rsc.]
Ini adalah masalah nyata yang sudah ada sebelumnya yang tidak coba ditangani oleh proposal vgo secara langsung, tetapi jelas kita harus mengatasinya pada akhirnya. Jawaban atas hilangnya kode adalah memiliki proxy caching (mirror) bersama dengan alasan untuk mempercayainya; itu pekerjaan masa depan. (Atau gunakan vendoring di proyek tingkat atas jika Anda mau.) Jawaban untuk pemindahan kode adalah dengan menambahkan konsep eksplisit dari pengalihan modul atau paket, seperti halnya alias tipe adalah pengalihan tipe; itu juga pekerjaan masa depan.

Bagaimana dengan menghubungkan ke server Git lokal?

[ https://github.com/golang/go/issues/24301#issuecomment -383168012 oleh @korya.]

Akses git langsung telah ditambahkan kembali ke paket. Lihat #24915.

Bagaimana dengan paket biner saja?

[ https://github.com/golang/go/issues/24301#issuecomment -382793364 oleh @sdwarwick.]

Paket-paket khusus-biner hanya pernah didukung dalam keadaan terbatas dari beberapa jenis instalasi out-of-band ke dalam GOPATH/pkg. Go get tidak pernah mendukung pengambilan dan pemasangan paket biner saja, dan itu akan terus tidak mendukungnya. Paket biner saja hanya berfungsi dengan satu kompiler tertentu dan satu salinan dependensi tertentu, yang sangat membatasi seberapa baik dapat didukung sama sekali. Jawaban yang benar hampir selalu menggunakan kode sumber.

Haruskah kita menggunakan sintaks path@version di file go.mod?

[ https://github.com/golang/go/issues/24301#issuecomment -382791513 oleh @sdwarwick.]

Ini #24119. Sepertinya ide yang bagus pada awalnya tetapi, setelah mempertimbangkan dengan cermat, tidak.

.

.

Ubah https://golang.org/cl/101678 menyebutkan masalah ini: design: add 24301-versioned-go

Proposal ini sangat mengesankan dan saya paling menyukai segala sesuatu tentangnya. Namun, saya memposting kekhawatiran berikut di milis, tetapi tidak pernah menerima balasan apa pun. Sementara itu saya telah melihat masalah ini diangkat oleh orang lain di saluran slack Gophers untuk vgo dan juga belum melihat jawaban yang memuaskan di sana.

Dari: https://groups.google.com/d/msg/golang-dev/Plc42fslQEk/rlfeNlazAgAJ

Saya paling khawatir tentang jalur migrasi antara dunia pra-vgo dan dunia vgo menjadi buruk. Saya pikir kami berisiko menimbulkan masalah besar pada komunitas Go jika tidak ada jalur migrasi yang mulus. Jelas migrasi tidak dapat bersifat atomik di seluruh komunitas, tetapi jika saya telah memahami semua yang telah Anda tulis tentang vgo sejauh ini, mungkin ada beberapa situasi di mana paket yang digunakan secara luas tidak akan dapat digunakan oleh alat dan pos pra-vgo - alat vgo.

Secara khusus, saya percaya bahwa paket yang sudah ada yang telah menandai rilis dengan versi utama >= 2 tidak akan bekerja dengan vgo sampai mereka memiliki file go.mod dan juga diimpor dengan jalur impor tambahan /vN. Namun, setelah perubahan tersebut dilakukan pada repositori, itu akan menghentikan penggunaan paket sebelum vgo.

Hal ini tampaknya menciptakan masalah impor berlian yang berbeda di mana dua paket saudara di tengah berlian mengimpor paket v2+ yang sama. Saya khawatir bahwa paket saudara harus mengadopsi jalur impor vgo secara atom untuk mencegah paket di bagian atas berlian berada dalam keadaan tidak dapat dibangun apakah itu menggunakan alat vgo atau pra-vgo.

Saya belum melihat apa pun yang menjelaskan jalur migrasi dalam skenario ini.

Proposal tersebut menyatakan:

Build modul-aware dapat mengimpor paket non-modul-aware (yang berada di luar pohon dengan file go.mod) asalkan diberi tag dengan versi semantik v0 atau v1. Mereka juga dapat merujuk ke komit tertentu menggunakan "versi semu" dari bentuk v0.0.0-yyyymmddhhmmss-commit. Bentuk versi semu memungkinkan merujuk ke komit yang tidak ditandai serta komit yang ditandai dengan versi semantik di v2 atau lebih tinggi tetapi yang tidak mengikuti konvensi versi impor semantik.

Tapi saya tidak melihat cara untuk paket non-modul-aware untuk mengimpor paket modul-sadar dengan dependensi transitif >= v2. Hal itu tampaknya menyebabkan fragmentasi ekosistem dengan cara yang belum tertangani. Setelah Anda memiliki ketergantungan modul-sadar yang memiliki paket >= v2 di suatu tempat dalam dependensi transitifnya yang tampaknya memaksa semua tanggungannya untuk juga mengadopsi vgo agar build tetap berfungsi.

Pembaruan: lihat juga https://github.com/golang/go/issues/24454

Proyek Go telah mendorong konvensi ini sejak awal proyek, tetapi proposal ini memberinya lebih banyak gigi: pemutakhiran oleh pengguna paket akan berhasil atau gagal hanya jika pembuat paket mengikuti aturan kompatibilitas impor.

Tidak jelas bagi saya apa artinya ini dan bagaimana perubahannya dari situasi saat ini. Tampaknya bagi saya, bahwa ini juga menggambarkan situasi saat ini: Jika saya melanggar aturan ini, peningkatan dan go-get akan gagal. AIUI tidak ada yang benar-benar berubah dan saya sarankan menghapus setidaknya penyebutan "lebih banyak gigi". Kecuali, tentu saja, paragraf ini dimaksudkan untuk menyiratkan bahwa ada mekanisme tambahan untuk menghukum/mencegah kerusakan?

Ini juga akan mempengaruhi hal-hal seperti driver database dan format gambar yang mendaftarkan diri dengan paket lain selama init, karena beberapa versi utama dari paket yang sama dapat melakukan hal ini. Tidak jelas bagi saya apa dampak dari semua itu.

Jika versi mayor adalah v0 atau v1, maka elemen nomor versi harus dihilangkan; jika tidak, itu harus disertakan.

Kenapa ini? Dalam posting tertaut, saya hanya melihat alasan bahwa inilah yang saat ini dilakukan pengembang untuk membuat jalur alternatif ketika mereka membuat perubahan yang melanggar - tetapi ini adalah solusi untuk fakta bahwa mereka pada awalnya tidak merencanakan perkakas yang tidak menangani versi untuk mereka . Jika kita beralih ke praktik baru, mengapa tidak mengizinkan dan mendorong (atau bahkan mengamanatkan) bahwa paket baru yang mendukung vgo menyertakan v0 atau v1 ? Sepertinya jalur yang tidak memiliki versi hanyalah peluang untuk kebingungan. (Apakah ini paket gaya vgo? Di mana batas modul? dll.)

Saya biasanya menyukai proposal tersebut, tetapi saya terpaku pada persyaratan versi utama di jalur impor:

1. Itu melanggar prinsip KERING ketika versi utama sudah dapat diketahui dari go.mod . Memahami apa yang akan terjadi jika ada ketidakcocokan antara keduanya juga sulit untuk ditebak.
2. Ketidakteraturan membiarkan v0 dan v1 tidak ada juga tidak intuitif.
3. Mengubah semua jalur impor saat memutakhirkan ketergantungan tampaknya berpotensi membosankan.

Saya mengerti bahwa skenario seperti contoh moauth harus bisa diterapkan, tetapi mudah-mudahan tidak mengorbankan hal-hal sederhana untuk skenario yang lebih umum.

Pertama-tama: Pekerjaan yang mengesankan!

Satu hal yang sama sekali tidak jelas bagi saya dan tampaknya agak kurang spesifik:

Mengapa ada file zip dalam proposal ini?

Tata letak, batasan, dan beberapa kasus penggunaan seperti kapan dibuat dan bagaimana siklus hidupnya dikelola, alat apa yang memerlukan dukungan, bagaimana alat seperti linter harus berinteraksi dengannya juga tidak jelas, karena tidak tercakup dalam proposal.

Jadi saya menyarankan untuk merujuk ke proposal nanti, yang masih belum tertulis, di sini dan menghapus kata zip atau menghapus seluruh bagian dari teks proposal, jika Anda berencana untuk tidak membahasnya sama sekali dalam lingkup proposal ini.

Membahas ini nanti juga memungkinkan audiens yang berbeda untuk berkontribusi lebih baik di sini.

Zona waktu mana yang digunakan untuk stempel waktu dalam versi semu (v0.0.0-yyyymmddhhmmss-commit)?

Sunting:
Itu dalam UTC sebagaimana dinyatakan dalam https://research.swtch.com/vgo-module.

@rsc Apakah Anda akan menangani dependensi C?

Sepertinya pemilihan versi Minimal membuat penyebaran perubahan yang tidak melanggar menjadi sangat lambat. Misalkan kita memiliki perpustakaan Foo yang populer, yang digunakan oleh proyek A,B dan C. Seseorang meningkatkan kinerja Foo tanpa mengubah API. Saat ini menerima pembaruan adalah proses opt-out. Jika proyek A menjual Foo, tetapi B dan C tidak, penulis hanya perlu mengirim pr dengan pembaruan ke ketergantungan vendor ke A. Jadi kontribusi pemutusan non-api tidak akan banyak berpengaruh pada komunitas dan agak tidak disarankan dibandingkan dengan saat ini situasi. Ini bahkan lebih bermasalah untuk pembaruan keamanan. Jika beberapa proyek yang ditinggalkan/kecil/tidak terlalu aktif (bukan perpustakaan) menyatakan ketergantungan langsung pada versi lama misalnya x/crypto, semua pengguna proyek itu akan rentan terhadap cacat di x/crypto hingga proyek diperbarui, berpotensi selamanya. Saat ini pengguna proyek tersebut akan menerima versi tetap terbaru, jadi ini membuat situasi keamanan menjadi lebih buruk. IIRC ada beberapa saran bagaimana memperbaikinya dalam diskusi maillist, tetapi, sejauh yang saya tahu proposal ini tidak menyebutkannya.

IIRC ada beberapa saran bagaimana cara memperbaiki [mendapatkan patch keamanan] dalam diskusi maillist, tetapi, sejauh yang saya tahu proposal ini tidak menyebutkannya.

Lihat penyebutan go get -p .

Lihat penyebutan go get -p.

Saya telah melihatnya, tetapi ini masih merupakan mekanisme keikutsertaan.
Saya sedang memikirkan cara bagi perpustakaan untuk menandai semua rilis sebelumnya sebagai tidak aman, untuk memaksa pengguna menjalankan go get -p atau secara eksplisit ikut serta ke perpustakaan yang tidak aman.

Jika dukungan untuk go get seperti yang kita kenal sekarang akan ditinggalkan dan akhirnya dihapus, apa cara yang disarankan untuk mengambil & menginstal (tanpa tanda) Go binari? Apakah itu memerlukan git clone 'ing proyek terlebih dahulu, diikuti dengan manual go install untuk menginstal biner?
Jika $GOPATH tidak digunakan lagi, di mana binari ini akan dipasang?

@leonklingele : dari pemahaman saya, go get tidak akan ditinggalkan, sebaliknya.
Ini akan ditingkatkan dengan kemampuan versi otomatis dan transparan. Jika sebuah proyek bergantung dari proyek yang tidak ditandai, itu hanya akan membutuhkan master dan "vendor" pada versi yang tepat ini.
Sekali lagi, pemahaman saya sendiri dari membaca sedikit tentang vgo. Saya masih dalam proses untuk memahaminya sepenuhnya.

Saya bertanya-tanya bagaimana ini akan memengaruhi alur kerja dengan repositori Git secara umum, juga membangun kalimat ini dari proposal:

Jika versi mayor adalah v0 atau v1, maka elemen nomor versi harus dihilangkan; jika tidak, itu harus disertakan.

Saat ini, tampaknya umum untuk bekerja pada master (bagi saya ini termasuk cabang fitur berumur pendek) dan untuk menandai komit dengan versi baru sesekali. Saya merasa alur kerja ini dibuat lebih membingungkan dengan modul Go segera setelah saya merilis v2 perpustakaan saya, karena sekarang saya memiliki cabang master dan v2 . Saya berharap master menjadi cabang saat ini dan v2 menjadi cabang pemeliharaan, tetapi justru sebaliknya.

Saya tahu bahwa cabang default dapat diubah dari master menjadi v2 , tetapi ini masih memberi saya tugas untuk memperbaruinya setiap kali saya merilis versi utama yang baru. Secara pribadi, saya lebih suka memiliki cabang master dan v1 , tetapi saya tidak yakin bagaimana tepatnya ini akan sesuai dengan proposal.

Rilis besar baru menyebabkan churn. Jika Anda harus mengubah satu pengaturan di repositori Git Anda (cabang default) setiap kali Anda membuat rilis baru, itu adalah biaya yang sangat kecil dibandingkan dengan pengguna perpustakaan Anda yang beralih ke versi baru.

Saya pikir aspek proposal ini menetapkan insentif yang tepat: mendorong penulis hulu untuk berpikir tentang bagaimana mereka dapat melakukan perubahan dengan cara yang kompatibel ke belakang, mengurangi churn ekosistem secara keseluruhan.

sekarang saya memiliki master dan cabang v2

Anda dapat membuat subdirektori v2/ di master.

@mrkanister

Saya lebih suka memiliki master dan cabang v1, tetapi saya tidak yakin bagaimana tepatnya ini akan sesuai dengan proposal.

Menurut pemahaman saya tentang https://research.swtch.com/vgo-module vgo menggunakan tag bukan cabang untuk mengidentifikasi versi. Jadi, Anda dapat mempertahankan pengembangan pada master dan cabang v1 selama tag menunjuk ke cabang yang benar dan komit.

Rilis besar baru menyebabkan churn. Jika Anda harus mengubah satu pengaturan di repositori Git Anda (cabang default) setiap kali Anda membuat rilis baru, itu adalah biaya yang sangat kecil dibandingkan dengan pengguna perpustakaan Anda yang beralih ke versi baru.

Ini adalah gaya berpikir bermasalah yang menurut saya telah menggigit Go hard di masa lalu. Untuk satu orang di satu proyek, mengganti cabang apa yang default saat ini sederhana, ya. Tetapi bertentangan dengan konvensi alur kerja akan membuat orang lupa, terutama ketika mereka bekerja dalam beberapa bahasa. Dan itu akan menjadi satu lagi contoh unik tentang bagaimana Go melakukan hal-hal yang sama sekali berbeda yang harus dipelajari oleh pendatang baru. Melawan konvensi alur kerja programmer umum _sama sekali_ biaya kecil.

Melawan konvensi alur kerja programmer umum sama sekali bukan biaya kecil.

Tidak mengikuti jalur konvensional terkadang merupakan kondisi yang diperlukan untuk inovasi.

Jika saya memahami bagian dari proposal dengan benar, Anda tidak perlu membuat subdirektori atau cabang baru. Anda berpotensi hanya memiliki cabang master dan git menandai repo Anda dari 0.0, ke 1.0, ke 2.0 dan seterusnya selama Anda memastikan untuk memperbarui go.module Anda ke jalur impor yang benar untuk perpustakaan Anda.

@mrkanister Saya pikir, untuk dev, klon master Anda (atau cabang dev apa pun) dan gunakan arahan "ganti" (lihat vgo-tour) untuk mengarahkannya. (jika saya mengerti apa yang Anda maksud, tidak yakin).

@rsc Saya ingin meminta Anda untuk lebih tepat tentang peta jalan dan apa yang harus kita lakukan sekarang.
Apakah akan mengikuti kebijakan Go dan fitur freeze vgo pada 3 bulan (2 sekarang) ?
Haruskah kita sekarang pergi dengan tongkat peziarah kita meminta setiap pengelola libs untuk menambahkan file go.mod atau haruskah kita menunggu proposal diterima secara resmi (untuk memastikan bahwa nama dan sintaks tidak akan berubah)?

@flibustenet Tools tidak tercakup dalam kebijakan 1.0 jadi apapun bisa berubah.

https://golang.org/doc/go1compat

Terakhir, toolchain Go (compiler, linker, build tools, dan sebagainya) sedang dalam pengembangan aktif dan dapat mengubah perilaku. Ini berarti, misalnya, skrip yang bergantung pada lokasi dan properti alat mungkin rusak oleh pelepasan titik.

Juga dari proposal

Rencananya, tergantung pada persetujuan proposal, adalah merilis dukungan modul di Go 1.11 sebagai fitur opsional yang masih dapat berubah. Rilis Go 1.11 akan memberi pengguna kesempatan untuk menggunakan modul "secara nyata" dan memberikan umpan balik kritis. Meskipun detailnya mungkin berubah, rilis mendatang akan dapat menggunakan pohon sumber yang kompatibel dengan Go 1.11. Misalnya, Go 1.12 akan memahami cara menggunakan sintaks file go.mod Go 1.11, meskipun saat itu sintaks file atau bahkan nama file telah berubah. Dalam rilis selanjutnya (misalnya, Go 1.12), kami akan menyatakan dukungan modul selesai. Dalam rilis selanjutnya (misalnya, Go 1.13), kami akan mengakhiri dukungan untuk go get non-modul. Dukungan untuk bekerja di GOPATH akan berlanjut tanpa batas waktu.

Terima kasih untuk umpan baliknya.

@AlexRouSg

Menurut pemahaman saya tentang https://research.swtch.com/vgo-module vgo menggunakan tag bukan cabang untuk mengidentifikasi versi. Jadi, Anda dapat mempertahankan pengembangan pada master dan cabang v1 selama tag menunjuk ke cabang yang benar dan komit.

Anda benar, ini akan terus berfungsi seperti sebelumnya (cukup periksa dua kali untuk memastikan), tangkapan bagus!

Dengan itu, hal yang saya (dan tampaknya orang lain) tidak mengerti adalah alasan di balik pelarangan paket v1 ada. Saya mencoba mengimpor satu menggunakan /v1 di akhir impor dan juga menambahkannya ke go.mod dari paket yang diimpor, tetapi vgo akan mencari folder bernama v1 sebagai gantinya.

@mrkanister
Saya pikir alasan utama untuk tidak mengizinkan v1 atau v0 di jalur impor adalah untuk memastikan bahwa hanya ada satu jalur impor untuk setiap versi paket yang kompatibel.
Menggunakan jalur impor biasa alih-alih /v1 adalah untuk memudahkan transisi, jadi Anda tidak perlu memperbarui semua jalur impor untuk menambahkan /v1 di akhir.

Hai,

Meskipun banyak poin dalam proposal ini disambut baik dan akan membantu menjinakkan basis kode Go besar yang muncul seiring waktu, aturan "gunakan versi minimal" cukup berbahaya:

• Anda ingin ekosistem kode Anda berkembang. Itu berarti Anda ingin orang menguji dan menggunakan versi baru serta mendeteksi masalah lebih awal sebelum menumpuk.
• Anda ingin rilis modul baru, yang memperbaiki masalah keamanan, untuk diterapkan sesegera mungkin
• Anda ingin dapat menerapkan rilis modul baru, yang memperbaiki masalah keamanan, sesegera mungkin. Mereka tidak selalu ditandai pada perbaikan keamanan. Jika Anda menghindari rilis baru, Anda juga menghindari perbaikan itu
• bahkan ketika rilis baru tidak berisi perbaikan keamanan yang menerapkan perubahannya lebih awal berarti akan ada lebih sedikit perubahan untuk diperiksa ketika rilis berikutnya yang berisi perbaikan keamanan diterbitkan (dan hal terakhir yang Anda inginkan ketika rilis tersebut diterbitkan dan Anda perlu menjadi cepat berarti terjebak dalam perubahan perantara yang tidak Anda lihat sebelumnya).
• menerapkan rilis perantara hanya berbahaya jika mereka merusak compat, dan mereka tidak boleh merusak compat, dan jika mereka merusak compat lebih baik untuk mendeteksinya dan memberi tahu penulis modul sebelum mereka menjadikannya kebiasaan untuk rilis berikutnya Anda akhirnya akan benar-benar membutuhkan.
• Anda tidak ingin potongan kode lama menyeret Anda ke bawah karena mereka masih menentukan versi ketergantungan kuno dan tidak ada yang menemukan waktu untuk memperbarui manifesnya. Menggunakan versi terbaru dari rilis utama melayani kebutuhan sosial ini di ekosistem kode lain: paksa pengembang untuk menguji versi terbaru dan tidak menunda sampai terlambat karena "ada hal yang lebih penting" (yaitu lebih menyenangkan) untuk dilakukan.
  
  
  
  • sementara secara teori, Anda dapat mengirimkan versi modul dalam jumlah tak terbatas sehingga setiap bagian kode dapat menggunakan yang diinginkan, dalam praktiknya segera setelah Anda membuat dua modul yang menggunakan dep yang sama Anda harus memilih versi sehingga semakin kompleks Anda perangkat lunak, semakin sedikit Anda akan mentolerir beberapa versi. Jadi Anda segera menemukan masalah lama tentang apa yang harus dilakukan dengan orang-orang yang tersesat yang memperlambat seluruh konvoi. Saya tidak pernah bertemu dengan budaya manusia yang mengatasi masalah ini dengan mengatakan kepada orang-orang yang tersesat "Anda benar, berjalanlah sepelan yang Anda mau, semua orang akan menunggu Anda". Mungkin bagus dan altruistik tetapi tidak produktif.
  
  

Melawan kelembaman manusia itu sulit dan menyakitkan, dan kami melawannya karena itu diperlukan untuk maju bukan karena itu menyenangkan. Membuat alat yang menyenangkan yang menghindari masalah dan mendorong manusia untuk menunda-nunda lagi tidak membantu sama sekali itu hanya akan mempercepat sedimentasi proyek dan akumulasi utang teknis. Sudah ada lusinan proyek Go di github dengan sebagian besar readme mereka dikhususkan untuk penulis memohon penggunanya untuk memutakhirkan karena dia membuat perbaikan penting, default ke rilis tertua akan menggeneralisasi masalah.

Aturan yang baik adalah "gunakan rilis terbaru yang cocok dengan rilis utama, tidak setiap komit perantara". Itu akan menjadi kompromi ke depan dan stabilitas. Ini menempatkan proyek asli dalam perintah, yang paling mengetahui basis kode, dan dapat memutuskan dengan bijaksana kapan harus mengalihkan penggunanya ke status kode baru.

Pertanyaan saya yang belum terjawab disalin dari milis:

Kami berharap bahwa sebagian besar pengembang akan lebih memilih untuk mengikuti konvensi "cabang utama" yang biasa, di mana versi utama yang berbeda tinggal di cabang yang berbeda. Dalam hal ini, direktori root di cabang v2 akan memiliki go.mod yang menunjukkan v2, seperti ini:

Sepertinya ada subdirektori dan konvensi cabang utama ini yang keduanya didukung oleh vgo. Dalam pengalaman anekdot saya, tidak ada repositori yang mengikuti konvensi ini dalam Go atau bahasa lain (tidak dapat benar-benar memikirkan satu pun selain yang dipaksakan oleh gopkg.in yang tampaknya relatif tidak digunakan akhir-akhir ini). Cabang master adalah yang terbaru dan memiliki tag v2.3.4 dalam riwayatnya. Tag ada untuk memisahkan semuanya (bukan hanya versi minor). Jika perlu untuk menambal versi lama, cabang dibuat sementara dari tag v1 terakhir, komit didorong, tag baru didorong, dan cabang segera dihapus. Tidak ada cabang untuk versi, hanya cabang master/dev/fitur + tag versi saat ini. Saya tahu bahwa "semuanya adalah referensi" di Git, tetapi untuk VCS lain perbedaannya mungkin tidak terlalu kabur.

Karena itu, saya telah menguji alur kerja yang dijelaskan di atas dengan vgo (hanya memiliki tag yang mengatakan v2.0.0, v2.0.1 dan tidak ada cabang) dan tampaknya berhasil. Jadi pertanyaan saya adalah: Meskipun ini berfungsi sekarang, apakah ini dimaksudkan? Karena sepertinya tidak dijelaskan secara menyeluruh seperti dua alur kerja lainnya di blog, dan saya ingin memastikan bahwa bekerja tanpa cabang v2/v3... bukanlah fungsionalitas yang tidak disengaja yang akan hilang karena seperti yang saya jelaskan di atas, saya tidak pernah melihat ini (atau yang lain) menggambarkan alur kerja di pos untuk diadopsi secara besar-besaran oleh siapa saja (terutama di luar komunitas Go).

Tentu saja argumen saya turun ke preferensi dan anekdot, jadi saya bersedia melakukan beberapa pengikisan ulang untuk membuktikan ini di semua bahasa jika diperlukan. Sejauh ini saya sangat menyukai posting proposal dan secara umum setuju dengan perubahan, akan terus mengikuti dan bermain dengan vgo.

Terima kasih untuk semua usaha Anda.

Dapatkah seseorang mungkin mengklarifikasi bagaimana model alternatif yang diusulkan untuk MVS akan bekerja untuk meningkatkan irama pemutakhiran? Karena bagi saya tidak jelas. Pemahaman saya tentang model alternatif (banyak digunakan) adalah

• Pengembang membuat manifes buatan tangan, mencantumkan batasan versi untuk semua dependensi yang digunakan
• Pengembang menjalankan $solver, yang membuat file kunci, mendaftar beberapa subset terpilih dari versi ketergantungan transitif yang memenuhi batasan yang ditentukan
• File kunci ini dikomit dan digunakan pada waktu pembuatan dan pemasangan untuk menjamin pembuatan yang dapat direproduksi
• Saat versi baru dependensi dirilis dan akan digunakan, pengembang berpotensi memperbarui manifes, menjalankan kembali solver, dan mengkomit ulang file kunci baru

Model MVS yang diusulkan seperti yang saya pahami

• Pengembang membuat otomatis go.mod , berdasarkan kumpulan jalur impor dalam modul, memilih versi terbaru dari semua ketergantungan transitif
• go.mod dikomit dan digunakan untuk mendapatkan batas bawah pada versi pada waktu pembuatan dan penginstalan. MVS menjamin build yang dapat direproduksi
• Ketika versi baru dependensi dirilis dan akan digunakan, pengembang menjalankan vgo get -u , yang mengambil versi dependensi transitif terbaru dan menimpa go.mod dengan batas bawah yang baru. Itu kemudian akan diajukan.

Sepertinya saya harus mengabaikan sesuatu dan akan sangat membantu jika seseorang menunjukkan apa. Karena pemahaman ini tampaknya menyiratkan bahwa karena lockfiles menentukan versi yang tepat dan yang digunakan dalam build yang sebenarnya, bahwa MVS lebih baik dalam meningkatkan irama pemutakhiran - karena tidak memungkinkan menahan versi, secara umum.

Jelas saya kehilangan sesuatu (dan akan merasa bodoh dalam jarak sekitar 5m), apa itu?

@tpng

Menggunakan jalur impor biasa alih-alih /v1 adalah untuk memudahkan transisi, jadi Anda tidak perlu memperbarui semua jalur impor untuk menambahkan /v1 di akhir.

Ini sebenarnya tidak perlu . Mari saya beri contoh:

Seorang pengguna saat ini menggunakan misalnya v1.0.0 dari perpustakaan, disematkan oleh manajer ketergantungan dan tag di repositori upstream. Sekarang upstream memutuskan untuk membuat go.mod dan juga memanggil modul /v1 . Ini akan menghasilkan komit baru dan tag baru (misalnya v1.0.1 ). Karena vgo tidak akan pernah mencoba memperbarui dependensinya sendiri, ini seharusnya tidak merusak apa pun bagi pengguna, tetapi ia dapat memperbarui secara sadar dengan juga mengubah jalur impor (pr vgo dapat melakukannya untuk dia).

Saya pikir alasan utama untuk tidak mengizinkan v1 atau v0 di jalur impor adalah untuk memastikan bahwa hanya ada satu jalur impor untuk setiap versi paket yang kompatibel.

Ya, saya kira saya memang bisa melihat hal itu agar tidak membingungkan pengguna baru perpustakaan.

Jika versi mayor adalah v0 atau v1, maka elemen nomor versi harus dihilangkan; jika tidak, itu harus disertakan.

Dapatkah seseorang tolong jelaskan alasan di balik ini? Apa yang harus saya lakukan, sebagai pengguna perpustakaan, ketika saya belum ingin menggunakan v1, karena memperkenalkan perubahan yang melanggar, yang akan baik-baik saja dengan versi semantik (versi utama baru)?

Saya lebih suka untuk hanya menghilangkan versi sebelum versi 1, yang menunjukkan paket yang tidak stabil/belum selesai. Mulai dari versi 1, saya ingin dapat mengandalkan fakta bahwa saya mendapatkan rilis yang stabil. Menghilangkan v1 di jalur impor membingungkan, karena Anda tidak tahu apakah Anda melacak perpustakaan yang selalu berubah atau versi stabil. Saya pikir ini juga tidak bekerja dengan baik dengan skema pembuatan versi semantik, di mana v1 menunjukkan dengan tepat rilis stabil pertama, yang digunakan untuk membedakan dengan jelas versi tersebut dari versi 0.x.

@kaikuehne

Apa yang harus saya lakukan, sebagai pengguna perpustakaan, ketika saya belum ingin menggunakan v1, karena memperkenalkan perubahan yang melanggar, yang akan baik-baik saja dengan versi semantik (versi utama baru)?

Sejauh yang saya pahami, vgo tidak akan pernah memperbarui dependensinya sendiri, bahkan ke versi tambalan, tetapi biarkan ini sebagai keputusan sadar untuk Anda buat. Jadi, jika Anda bergantung pada v0.4.5 dari perpustakaan (yang memiliki tag untuk itu), Anda secara teoritis dapat terus menggunakannya selamanya. Anda juga dapat menyematkan versi secara manual di file go.mod Anda.

Bagaimana jika ketergantungan lain yang saya gunakan bergantung pada paket yang sama, tetapi versi v1? Kedua paket diimpor menggunakan jalur impor yang sama. Apakah tidak ada konflik saat mengkompilasinya ke dalam biner yang sama?

Jika kita memerlukan v1 untuk juga menjadi bagian dari jalur impor, keduanya akan diperlakukan sebagai paket yang berbeda, yang merupakan jenisnya.

@kaikuehne maka itu akan memperbarui ke versi umum minimal yang berfungsi. (menurut pemahaman saya)

@kaikuehne Saya tidak mengerti alasan Anda. Anda menggunakan v0, jadi mungkin Anda baik-baik saja dengan melanggar perubahan; mengapa menjadi masalah jika v1 rusak, mengingat Anda sudah menggunakan versi yang tidak memiliki jaminan stabilitas? Lebih lanjut, katakanlah alih-alih beralih dari v0.1->v1.0 dengan perubahan yang melanggar, upstream akan menambahkan jeda ke v0.2 dan kemudian merilis v1.0 (tidak melanggar). Itu tampaknya baik dalam harapan di sekitar versi semantik, tetapi akan berjumlah jumlah kerja keras yang sama untuk Anda (tidak peduli manajer paket yang digunakan). Yaitu saya benar-benar tidak mengerti bagaimana "penulis tiba-tiba berhenti melanggar API mereka" merupakan masalah yang tidak disebabkan oleh penggunaan rilis pra-1.0.

Dengan kata lain: Dengan menggunakan v0.x, Anda menerima bahwa v0.(x+1) mungkin memaksa Anda untuk memperbaiki kode Anda. Mengapa menjadi masalah jika v0.(x+1) disebut v1.0?

Pada poin diskusi 4: Secara eksplisit mengadopsi aturan kompatibilitas impor dan "paket baru harus kompatibel dengan paket lama"...

Dalam kasus saya, saya memiliki paket keamanan https://github.com/microcosm-cc/bluemonday dan saya baru-baru ini (akhir tahun lalu) memiliki skenario di mana saya mengetahui bahwa fungsi publik pada dasarnya tidak sesuai untuk tujuan. Jadi saya menghapusnya.

Di bawah proposal ini, jika saya menghapus fungsi itu akan menabrak versi dan kode tidak aman/tidak aman tidak akan pernah dihapus.

Untuk menghindarinya, saya mungkin akan memilih log.Fatal() dalam fungsi yang ingin saya hapus, semata-mata untuk memastikan bahwa kode yang ada tidak menggunakan titik akhir yang tidak aman tetapi untuk menjaga kompatibilitas.

Mengingat bahwa tidak satu pun dari ini yang ideal... bagaimana kami memperkirakan perbaikan keamanan yang memerlukan fungsi publik untuk ditangani dengan susah payah? (jika tidak mengejutkan pengembang dengan log runtime.Fatal()?)

Bagi mereka yang ingin melihat komit untuk ini: https://github.com/microcosm-cc/bluemonday/commit/a5d7ef6b249a7c01e66856b585a359970f03502c

@Merovius Terima kasih atas klarifikasinya saat menggunakan versi 0.x. Seperti yang Anda katakan, tidak ada jaminan untuk diandalkan saat menggunakan versi sebelum 1.0 dan bahwa versi 0.x adalah kasus khusus di semver. Jika saya mengerti dengan benar, aturan yang diuraikan sebenarnya tidak berlaku untuk versi 0.x sama sekali. Pertanyaan saya adalah apakah masuk akal untuk mencerminkan perbedaan ini dalam kode juga -- terutama saat menamai paket. Misalnya, jika sebuah paket hanya mengimpor paket tanpa versi, Anda dapat melihat sekilas bahwa paket tersebut dibangun di atas kode yang tidak stabil. Jika semua impor berisi versi v1, Anda akan melihat bahwa itu menggunakan versi stabil.

@buro9 Proposal menyarankan kira-kira mengikuti jaminan kompatibilitas go1, yang berisi pengecualian untuk kerusakan API terkait keamanan.

@kaikuehne Terima kasih, itu menjelaskan kekhawatiran Anda.

Ada interaksi fitur yang saya khawatirkan (dengan asumsi saya memahami berbagai hal dengan benar).

Jika Anda memiliki modul M yang menggunakan versi reified (direktori vN literal di sumber, bukan elemen jalur impor sintetis yang berasal dari tag), dan Anda sedang membangun program P yang bergantung pada beberapa versi utama M secara transitif, bukankah begitu? harus melanggar pemilihan versi minimal dalam beberapa skenario?

Artinya, katakanlah P bergantung pada versi utama 2, 3, dan 4 dari M. Untuk setiap versi utama M, ada versi lengkap minimal yang ditentukan. Karena versi M berbagi sumber untuk tujuan yang jelas agar dapat melakukan hal-hal seperti secara transparan menggunakan definisi tipe yang sama dengan alias tipe, maka hanya satu salinan M yang dapat disertakan untuk ketiga versi utama alih-alih satu salinan per versi utama. Pilihan versi lengkap apa pun untuk satu versi utama memperbaiki pilihan untuk versi lengkap dari dua versi utama lainnya dan dapat menyebabkan pemilihan versi non-minimal untuk satu atau kedua versi utama lainnya.

Bagaimana vgo menangani ini? Bisakah ini menyebabkan masalah selain terkadang menjadi sedikit kurang dari minimal? (Sepertinya mungkin untuk secara tidak sengaja membangun satu set modul yang tidak menghasilkan solusi atau menyebabkan pemecah untuk mengulang?)

@jimmyfrasche

Jika Anda menggunakan direktori versi utama, vgo akan tetap menggunakan tag dan hanya mendapatkan folder versi yang cocok dari tag tersebut. misalnya Anda bergantung pada versi 2, 3, 4. vgo akan memeriksa tag v2.nm, v3.nm, v4.nm
Dan kemudian dari tag v2.nm hanya mendapatkan folder v2 dan seterusnya. Jadi pada akhirnya semuanya masih mengikuti tag.

Saya mengajukan pertanyaan di pos milis ini, tetapi belum melihat jawaban yang konkret. Saya akan mengulanginya di sini:

apa yang akan terjadi dengan sumber daya non-Go, seperti protobuf atau file c? Maaf jika ini sudah dijawab dalam posting Anda, tetapi kami menggunakan jalur vendor untuk mendistribusikan dan mengatur jalur impor untuk file protobuf. Sementara kami akan mengkompilasi paket Go terhadap keluaran protobuf yang telah dikompilasi sebelumnya, kami juga harus mempertimbangkan kasus kompilasi paket Go baru dari file protobuf yang bergantung pada dependensi vendor (yaitu referensi rpc.Status dari file protobuf lain). Saya dapat memberikan beberapa contoh yang lebih konkret jika deskripsi itu terlalu padat.

Secara khusus, saya memiliki proyek bernama protobuild yang memungkinkan seseorang untuk memetakan impor file protobuf ke lokasi GOPATH. Saya tidak melihat bagaimana proposal ini akan menangani resolusi sumber daya di GOPATH dan bagaimana kami dapat memetakannya ke ruang impor kompiler lainnya.

Ini adalah masalah besar untuk bekerja dengan protobuf bagi kami dan proyek ini mengurangi banyak masalah tersebut. Sayang sekali jika ini sama sekali tidak sesuai dengan proposal.

Sekali lagi, mohon maaf jika ada yang saya lewatkan.

Saya suka proposalnya. Saya hanya khawatir bahwa terlalu banyak proyek sering kali memperkenalkan perubahan kecil antara versi minor dan cadangan versi utama hanya untuk perubahan yang sangat besar. Jika perubahan versi minor sering terjadi, maka masalah ketergantungan berlian akan muncul karena melanggar asumsi SIV. Saya ingin tahu apakah menyertakan versi minor dalam pernyataan impor akan membantu lebih banyak proyek mematuhi kontrak perubahan yang tidak melanggar. Saya pikir kerugiannya adalah churn impor ekstra dan memperbarui versi minor menjadi lebih sulit (dan lebih eksplisit).

Ini memunculkan pertanyaan lain yang saya miliki: apakah mudah (hari ini) dengan vgo untuk menentukan apakah Anda memiliki lebih dari 1 versi paket dalam sebuah build? Meskipun mengizinkan dua versi dari paket yang sama terkadang penting untuk bergerak maju, tampaknya sebagian besar proyek ingin menghindari hal ini kecuali untuk sementara karena kemungkinan efek samping yang tidak terduga dari init. Memiliki cara mudah untuk memeriksa ini mungkin berguna dan beberapa proyek mungkin ingin menerapkannya selama pemeriksaan kode.

Saya hanya khawatir bahwa terlalu banyak proyek sering kali memperkenalkan perubahan kecil antara versi minor dan cadangan versi utama hanya untuk perubahan yang sangat besar.

Perubahan yang melanggar adalah perubahan yang menghancurkan. Tidak boleh kecil atau besar. Saya kira paket seperti itu pada akhirnya akan ditolak oleh komunitas karena terlalu tidak dapat diandalkan dan tidak mengikuti semver. Bahkan jika mereka akan mengikuti semver dan dengan cepat mendapatkan nomor besar besar seperti 42.xx mereka tetap akan sangat merepotkan untuk digunakan. Jadi, jika Anda ingin membuat banyak perubahan, tetap gunakan angka utama 0. Cara ini akan terus berfungsi seperti go get saat ini, dengan masalah yang sama. Jika Anda ingin bereksperimen dengan API setelah merilis versi mayor non-0 - pindahkan eksperimen ini ke paket "eksperimental" yang terpisah dengan 0 mayor selamanya dan tingkatkan paket utama utama saat Anda selesai dengan "perubahan kecil" dan akhirnya dapatkan API stabil berikutnya.

Memasukkan minor dalam jalur impor melanggar ideologi semver dan tidak memberikan fitur baru apa pun selain mayor.

Sementara saya mengerti bahwa itulah yang harus dilakukan penulis mengingat semantik semver, ketakutan saya adalah bahwa perubahan kecil yang melanggar di antara versi kecil adalah kasus umum dan menggoda untuk seseorang yang sudah melewati versi 1. Dalam pengalaman anekdot saya, penulis paket tidak ikuti semantik yang tepat dari semver dan seringkali perusahaan mencadangkan versi utama gundukan untuk tujuan pemasaran. Jadi daya tarik saya bukan tentang apa yang ideal, tetapi tentang apakah mungkin praktis untuk membuat perubahan tertentu untuk menangani lebih baik realitas manusia yang berantakan yang semver.

Mungkin bahkan mungkin untuk secara opsional menyertakan versi minor untuk paket yang tidak mematuhi semver, mungkin itu mengacaukan seluruh proposal, saya harus lebih memikirkannya. Saya tidak mengusulkan ini adalah cara yang lebih baik hanya saja saya tertarik untuk mengeksplorasi lebih lanjut pertukaran baik secara opsional termasuk atau mengamanatkan penyertaan versi minor dalam impor.

Kemungkinannya adalah menghasilkan data yang lebih baik di sini dari go corpus (dan alat yang mencari perubahan yang jelas terlihat) untuk menentukan seberapa sering semver dikatakan paling banyak diikuti di antara proyek populer yang ada yang menggunakan tag semver.

proposal vgo memungkinkan versi utama untuk memecahkan perubahan API dengan anggun. Itu (dengan sendirinya) tidak melakukan apa pun untuk mencegah mereka.

proposal vgo memungkinkan satu versi utama untuk merujuk ke versi utama lainnya, memungkinkan penggunaan kembali kode yang anggun. Tidak ada gunanya memaksa itu.

proposal vgo MVS memungkinkan pembaruan ke paket yang lebih baru. Itu tidak memaksa Anda untuk memperbarui.

Berikut adalah hal-hal yang dapat kita bangun dengan lebih mudah di dunia vgo:

1. Alat untuk menangkap perubahan pengereman API sebelum mendorong ke host modul. Setiap versi dalam zip dan dapat dibandingkan tanpa banyak alat dan perintah vcs yang berbeda.
2. Registri masalah keamanan. Host di samping modul hosting untuk nilai tambah. Alat dapat memintanya mirip dengan go list baik secara manual atau otomatis dan mendapatkan pemberitahuan tentang masalah yang difilter oleh kueri.

vgo membuatnya lebih mudah dengan:

• Membatasi ruang masalah (hanya berfungsi dengan file Zip, tidak perlu menyimpan riwayat git/hg/svn sewenang-wenang untuk melakukan perbandingan API).
  
  
  
  • Mendefinisikan ruang masalah (MVS, definisi versi)
  
  
• Perkakas bagian build.

vgo beroperasi pada satu prinsip utama: satu set input harus selalu membangun hal yang sama. Jika kami mengandalkan pembuatan ulang acak untuk menangkap pembaruan keamanan , kami melakukan kesalahan . Sebagai pengelola proyek, beberapa proyek Go hanya berjalan selama bertahun-tahun tanpa pembangunan kembali. Saya setuju bahwa pembaruan keamanan tepat waktu itu penting: vgo memenuhi bagian pembangunan dari kebutuhan ini.

Kita tidak boleh bingung antara apa yang diizinkan vgo dengan apa itu vgo.

@ pbx0 Saya tidak yakin apakah ini tempat yang tepat untuk diskusi seperti itu, mungkin daftar surat lebih cocok. Bagaimanapun, melanggar perubahan tanpa mengubah nomor utama terjadi. Bahkan sesekali. Semver telah menjawab kasus ini di FAQ:

Segera setelah Anda menyadari bahwa Anda telah merusak spesifikasi Versi Semantik, perbaiki masalah dan rilis versi minor baru yang memperbaiki masalah dan mengembalikan kompatibilitas ke belakang.

Tapi saya pikir ada tempat untuk perbaikan di sini. Saya kira itu harus cukup mudah untuk mengimplementasikan pemeriksa API otomatis (mungkin bahkan sudah ada), yang akan mengambil semua paket yang terdaftar di godoc.org dan secara berkala memeriksa versi baru, dan jika versi baru yang terdeteksi, pemeriksaan adalah versi baru yang kompatibel dengan versi sebelumnya. versi API jika menggunakan tag semver dan mayor tidak diubah. Kemudian coba hubungi penulis jika terdeteksi perubahan yang tidak kompatibel - mungkin masalah buka otomatis di github atau gunakan email dari akun github. Ini tidak akan mencakup semua kemungkinan kasus, tetapi mungkin sangat membantu bagi komunitas.

Saya sangat percaya dalam menggunakan jalur untuk menjangkau versi utama dan ingin menyuarakan dukungan saya, FWIW.

Setahun yang lalu, saya percaya bahwa menempatkan versi di jalur impor seperti ini jelek, tidak diinginkan, dan mungkin dapat dihindari. Tetapi selama setahun terakhir, saya mulai memahami betapa banyak kejelasan dan kesederhanaan yang mereka bawa ke sistem.

Hampir dua puluh tahun yang lalu saya membutuhkan VCS untuk startup saya dan mencoba sekitar sepuluh yang berbeda. Saya segera mengesampingkan Perforce karena mengekspos cabang menggunakan direktori. Jadi cabang v2 hanya akan menjadi kode yang sama, tetapi di bawah folder v2. Aku benci ide ini. Tetapi setelah menjalankan pilot dengan sembilan lainnya, saya menemukan bahwa saya sering ingin memiliki kedua versi cabang di sistem file lokal saya, dan ternyata Perforce membuatnya mudah sedangkan yang lain membuatnya sangat rumit. Sistem file adalah metafora penahanan kami. Mari kita gunakan.

Dari usulan:

Tentukan skema URL untuk mengambil modul Go dari proxy, digunakan baik untuk menginstal modul menggunakan nama domain khusus dan juga saat variabel lingkungan $GOPROXY disetel. Yang terakhir memungkinkan perusahaan dan individu untuk mengirim semua permintaan pengunduhan modul melalui proxy untuk keamanan, ketersediaan, atau alasan lainnya.

Saya telah menyebutkan ini di tempat lain, tetapi kekhawatiran terbesar saya dengan proposal ini adalah tampaknya membuang (atau setidaknya tidak membahas) salah satu kekuatan vendor terbesar saat ini: kode yang selalu tersedia dan build yang dapat direproduksi dengan sempurna. Saya tidak berpikir sistem proxy yang diusulkan alamat yang memadai atau menggantikan kekuatan ini.

Sebuah proyek yang menggunakan vendor saat ini hanya memerlukan toolchain Go dan Git (atau sistem kontrol versi lainnya). Hanya ada satu titik kegagalan: repositori git. Setelah kode diperiksa, kode dapat dibangun dan dibangun kembali dengan sempurna tanpa perlu menyentuh jaringan lagi -- pertimbangan keamanan yang penting. Bagi sebagian besar dari kita, proyek vendor tidak memerlukan infrastruktur tambahan -- hanya komputer lokal Anda dan akun GitHub gratis.

Ketergantungan vgo pada proxy memperkenalkan overhead infrastruktur non-sepele yang saya yakini tidak cukup ditekankan. Infrastruktur baru harus disediakan, diterapkan, dipelihara, dan dipantau. Ini mungkin masuk akal untuk organisasi perangkat lunak, tetapi merupakan beban bagi individu dan proyek sumber terbuka yang terdesentralisasi. Selain itu, hal-hal seperti CI sering dialihdayakan ke pihak ketiga seperti Travis CI, yang tidak berjalan di infrastruktur yang sama dengan lingkungan pengembangan perusahaan. Ini mempersulit penggunaan kembali infrastruktur proxy.

Bahasa lain memungkinkan penggunaan proxy caching. Python adalah yang paling banyak saya alami, dan menurut pengalaman saya, ini jarang digunakan karena biaya pengaturannya yang terlalu tinggi. Mungkin proyek Go dapat membuat ini lebih sederhana, tetapi jika ini bukan default, kami akan menganggapnya lebih jarang digunakan dan ketersediaan build Go di alam liar akan menurun secara substansial. Dampak dari event NPM di sisi kiri adalah studi kasus yang bagus dalam hal ini.

Jika modul dan sistem proxy memungkinkan kami untuk memeriksa dependensi bersama kode proyek kami sendiri (mirip dengan vendor hari ini, tetapi tidak harus implementasi yang sama) dan implementasi proxy vgo dapat menggunakannya, itu akan mengatasi masalah saya. Tapi kalau itu niatnya, saya kira perlu dibahas lebih lengkap dalam proposal.

@joeshaw Anda akan terus dapat menggunakan direktori vendor untuk membuat build mandiri.

Dari usulan:

Larang penggunaan direktori vendor, kecuali dalam satu penggunaan terbatas: direktori vendor di bagian atas pohon file modul tingkat atas yang sedang dibangun masih diterapkan ke build, untuk terus mengizinkan repositori aplikasi mandiri. (Mengabaikan direktori vendor lain memastikan bahwa Go kembali ke build di mana setiap jalur impor memiliki arti yang sama di seluruh build dan menetapkan bahwa hanya satu salinan paket dengan jalur impor tertentu yang digunakan dalam build tertentu.)

Sebuah proyek yang menggunakan vendor saat ini hanya memerlukan toolchain Go dan Git (atau sistem kontrol versi lainnya). Hanya ada satu titik kegagalan: repositori git.

Hari ini, jika Anda menghosting paket di bawah domain Anda sendiri, Anda perlu a) meng-host git-repository dan b) menyajikan tag <meta> yang diperlukan untuk go-get menemukannya. Di masa mendatang, Anda perlu a) menyajikan file .zip dan .json yang diperlukan vgo untuk mengambil kode. Tampaknya ada lebih sedikit titik kegagalan dan lebih sedikit infrastruktur yang dibutuhkan untuk hosting murni. Tentu saja Anda masih perlu meng-host repositori untuk pengembangan, tetapi tidak hanya membawa kita ke tingkat yang paling buruk seperti sebelumnya, repositori itu sendiri juga membutuhkan hosting yang jauh lebih sedikit skalabel dan andal, karena hanya digunakan oleh orang-orang yang benar-benar berkembang.

Jadi, untuk impor kesombongan, tampaknya tidak ada banyak perbedaan dalam hal overhead.

Jika, OTOH, Anda tidak menggunakan impor rias, Anda mengabaikan semua infrastruktur yang dijalankan github untuk Anda. Jadi ini sepertinya bukan perbandingan apel-dengan-apel: Satu-satunya cara Anda menjadi yang teratas adalah karena Anda membiarkan orang lain memecahkan masalah yang sulit. Tetapi tidak ada yang mencegah Anda melakukan itu di masa depan. AIUI Microsoft dan lainnya telah secara sukarela menginvestasikan jam teknis dan kapasitas pelayanan ke dalam tugas ini. Saya berharap bahwa di masa depan, upaya hosting paket Go akan secara kasar dibatasi lebih rendah oleh upaya hosting paket npm atau permata atau peti: Anda memiliki repositori github dan kemudian klik tombol "jadikan ini tersedia" di beberapa pusat layanan terkelola untuk meng-host ritsleting.

Ketergantungan vgo pada proxy

Secara pribadi, saya tidak suka kata "proxy" untuk apa yang dilakukan infrastruktur yang diperlukan. "Cermin" tampaknya lebih tepat. Mirror dapat diimplementasikan sebagai proxy, tetapi juga dapat berupa sekumpulan file yang disajikan oleh server web pilihan Anda, tersembunyi di balik cloudflare untuk skalabilitas dan waktu aktif yang kurang lebih tak terbatas.

Bahasa lain memungkinkan penggunaan proxy caching.

Saya berpendapat bahasa lain berfungsi sebagai model yang sangat baik mengapa ini tidak terlalu menjadi masalah. Mereka cenderung mengandalkan hosting terpusat untuk paket mereka ke paket host - vgo tidak hanya mendukung model ini dengan sangat baik, tetapi juga menjadikannya opsional (sehingga Anda mendapatkan semua keuntungan tanpa kerugian) dan sangat sederhana untuk mengimplementasikan, menskalakan, dan mengoperasikan.

IMO, jika Anda langsung membandingkan apa yang terjadi sebelum dan sesudah dan di Go dan dalam bahasa lain, harus jelas bahwa ada banyak kesetaraan 1:1. Dan satu-satunya alasan rasanya akan lebih banyak usaha di masa depan, adalah karena kita menganggap remeh infrastruktur yang ada dan melihat bahwa infrastruktur baru belum ada. Tapi saya tidak berpikir kita punya alasan bagus untuk meragukannya.

Jadi, untuk impor kesombongan, tampaknya tidak ada banyak perbedaan dalam hal overhead.

Benar, tetapi paket minoritas _vast_ menggunakan domain kesombongan, jadi saya rasa ini bukan tandingan yang kuat. (Saya juga memiliki masalah praktis lainnya dengan domain kesombongan, yaitu ketersediaannya cenderung _jauh lebih buruk_ daripada hanya menggunakan GitHub.)

Jika, OTOH, Anda tidak menggunakan impor rias, Anda mengabaikan semua infrastruktur yang dijalankan github untuk Anda.

Iya benar sekali! Saya merasa bahwa ini membuat poin saya untuk saya. Anda mendapatkan semua pekerjaan luar biasa pada infrastruktur dan mempertahankan waktu aktif secara gratis atau dengan biaya yang wajar. Lebih penting lagi, itu tidak melibatkan waktu Anda sendiri.

Jika GitHub akhirnya menjalankan vgo -cermin yang kompatibel, maka mungkin ini kurang menjadi perhatian, meskipun saya suka keanggunan satu Git fetch -- tindakan atom dari sudut pandang pengguna -- yang berisi semua kode Saya perlu membangun sebuah proyek.

Saya berpendapat bahasa lain berfungsi sebagai model yang sangat baik mengapa ini tidak terlalu menjadi masalah. Mereka cenderung mengandalkan hosting terpusat untuk paket mereka untuk meng-host paket - vgo tidak hanya mendukung model ini dengan sangat baik, tetapi juga menjadikannya opsional (sehingga Anda mendapatkan semua keuntungan tanpa kerugian) dan sangat sederhana untuk diterapkan, skala dan beroperasi.

Masalahnya adalah ini menambahkan titik kegagalan tunggal (SPOF) untuk membangun sebuah proyek. Kode tersebut akan hidup di VCS apa pun yang terjadi (dan mungkin GitHub), jadi itu salah satu SPOF. Dalam bahasa lain, repositori terpusat adalah SPOF kedua. Untuk Go, setiap jalur impor adalah SPOF tambahan (github.com, golang.org, honnef.co, rsc.io, dll.) dan meningkatkan SPOF akan menurunkan ketersediaan secara keseluruhan.

Menjalankan cermin dapat menguranginya menjadi dua, tentu saja, tetapi infrastruktur yang menurut saya tidak perlu ada. Vendor deps Anda (atau memiliki cermin lokal di disk) mengurangi ini kembali ke hanya satu: VCS Anda.

Bagaimanapun, ini mungkin poin yang bisa diperdebatkan. Saya awalnya tidak memahami bagian dari proposal tentang direktori vendor tingkat atas yang tampaknya akan menyelesaikan masalah utama saya -- terima kasih telah menunjukkan hal itu, @kardianos -- meskipun istirahat bersih dari yang lama sistem vendor mungkin lebih baik.

Saya senang bahwa "tingkat atas vendor " akan tetap menjadi konfigurasi yang didukung karena saya sangat menyukai git grep .

Menjalankan cermin dapat menguranginya menjadi dua, tentu saja, tetapi infrastruktur yang menurut saya tidak perlu ada.

Pengembang perusahaan di sini. Mungkin kami bukan target demografis, tetapi kami ingin menggunakan Go. Saya tidak dapat melihat itu terjadi tanpa kita memiliki cermin di dalam perusahaan kita, seperti yang kita lakukan untuk java dan javascript, untuk memastikan bahwa apa pun yang kita bangun hari ini dapat dibangun besok.

Pengembang perusahaan di sini. Mungkin kami bukan target demografis, tetapi kami ingin menggunakan Go. Saya tidak dapat melihat itu terjadi tanpa kita memiliki cermin di dalam perusahaan kita, seperti yang kita lakukan untuk java dan javascript, untuk memastikan bahwa apa pun yang kita bangun hari ini dapat dibangun besok.

@jamiethermo Apakah vendor tidak membahasnya untuk Anda hari ini?

Dukungan untuk proxy atau cermin baik-baik saja, dan jika itu membantu adopsi Go, saya setuju. Kekhawatiran saya adalah cermin sebagai pengganti pohon sumber lokal yang mandiri (apa yang kita sebut vendor hari ini).

@joeshaw

Apakah vendor tidak membahasnya untuk Anda hari ini?

Yah, saya harus mengakui ketidaktahuan, dan sejumlah frustrasi dengan "bagaimana saya harus mengatur kode saya". Dengan "pohon sumber mandiri", maksud Anda bahwa saya memiliki repo git raksasa yang berisi semua kode saya, ditambah semua kode di pohon vendor? Jadi saya tidak memerlukan cermin karena saya telah memeriksa semua kode lain itu ke dalam repo saya sendiri?

Berkenaan dengan "bagaimana saya harus mengatur kode saya", halaman ini, Cara Menulis Go Code , menginstruksikan tentang struktur direktori, tetapi tidak menyebutkan vendor.

Mengadopsi versi impor semantik, di mana setiap versi utama memiliki jalur impor yang berbeda. Secara khusus, jalur impor berisi jalur modul, nomor versi, dan jalur ke paket tertentu di dalam modul. Jika versi utama adalah v0 atau v1 , maka elemen nomor versi harus dihilangkan; jika tidak, itu harus disertakan.

Paket yang diimpor sebagai my/thing/sub/pkg , my/thing/v2/sub/pkg, dan my/thing/v3/sub/pkg berasal dari versi utama v1 , v2, dan v3 dari modul my/thing, tetapi build memperlakukan mereka hanya sebagai tiga paket berbeda.

my/thing/sub/pkg juga bisa v0.

Saya mengikuti tur . Contoh dibuat di luar pohon GOPATH, dan berfungsi, sedangkan dep init barf dalam situasi itu. Saya bekerja dengan, saya pikir, 80 tim sekarang, dan akan sangat menyenangkan untuk tidak memiliki satu pohon raksasa. (Saat saya mengetik ini, seseorang berjalan dengan laptop mereka dan wajah cemberut, dan "Saya punya bug yang sangat aneh ...")

@joeshaw

Anda mendapatkan semua pekerjaan luar biasa pada infrastruktur dan mempertahankan waktu aktif secara gratis atau dengan biaya yang wajar.

Saya mengucapkannya dengan buruk. Saya bermaksud mengatakan "jika Anda mengklaim bahwa Anda dulu membutuhkan lebih sedikit infrastruktur jika Anda tidak menggunakan impor kesombongan, Anda mengabaikan semua infrastruktur yang dijalankan github untuk Anda". Saya bermaksud menunjukkan bahwa infrastruktur masih ada dan masih perlu dijalankan. Dan itu dapat terus dijalankan untuk Anda di masa depan juga.

Jadi kekhawatiran Anda akan dibahas dalam apa yang saya anggap sebagai skenario yang paling mungkin: Bahwa badan yang didanai (saat ini sedang dibentuk oleh Microsoft) melakukan hosting file-file zip.

meskipun saya menyukai keanggunan pengambilan Git tunggal -- tindakan atom dari sudut pandang pengguna

vgo get sama seperti tindakan atomik dan kurang berhasil, dengan sifat yang sama (permintaan HTTP) yang lebih mudah dipahami.

Masalahnya adalah ini menambahkan titik kegagalan tunggal (SPOF) untuk membangun sebuah proyek.

Di mana komentar terakhir saya salah? Karena tampaknya cukup jelas bagi saya bahwa jumlah titik kegagalan, jika ada, kurang , mereka lebih sederhana, lebih mudah untuk diukur, dan lebih murah untuk dijalankan.

Dalam bahasa lain, repositori terpusat adalah SPOF kedua. Untuk Go, setiap jalur impor adalah SPOF tambahan (github.com, golang.org, honnef.co, rsc.io, dll.) dan meningkatkan SPOF akan menurunkan ketersediaan secara keseluruhan.

Saya pikir ini terlalu disederhanakan. Jika Anda meng-host kode Anda di mirror yang turun, maka Anda masih dapat mengembangkan (github masih aktif) dan pengguna mungkin masih dapat menginstal (dengan menggunakan mirror yang berbeda). Host salah satu dependensi Anda turun tidak masalah, karena Anda mencerminkan dependensi Anda. Jika Anda tidak memercayai mirror yang dijalankan komunitas "terpusat" untuk tetap terjaga, Anda dapat menjalankannya sendiri atau membayar seseorang untuk melakukannya, tanpa perbedaan bagi pengguna, memberi Anda kendali penuh atas seberapa besar Anda terpengaruh oleh waktu henti repo terpusat.

Tidak satu pun dari hal-hal yang Anda sebutkan sebenarnya adalah SPOF, karena Anda masih mendapatkan setidaknya operasi yang terdegradasi. Tambahkan ke itu, bahwa mirror yang sebenarnya relatif sepele untuk dioperasikan (karena mereka hanya server HTTP stateless) dan saya tidak yakin bahwa keandalan dan ketersediaan akan berkurang secara signifikan.

Dan FTR, saat ini git-hosting Anda adalah SPOF: Jika git-host Anda down, pengguna tidak dapat menginstal dan Anda tidak dapat mengembangkan.

Menjalankan cermin dapat menguranginya menjadi dua, tentu saja, tetapi infrastruktur yang menurut saya tidak perlu ada.

Dan poin saya (diungkapkan dengan buruk) di atas adalah, bahwa itu sudah terjadi :) Anda hanya a) mengabaikan bahwa itu terjadi sekarang dan b) dengan asumsi bahwa itu tidak akan terjadi di masa depan :)

Untuk memberikan perspektif yang berbeda:

• kami sedang membangun banyak proyek Go dengan manajer komponen perangkat lunak lintas bahasa seluruh sistem kami (rpm/dnf di Fedora, Centos, dan RHEL)
• itu memungkinkan kita menggunakan melakukan banyak trik yang sama seperti proposal vgo, dengan bermain di ruang nama komponen lapisan rpm (biasanya, mengganti nama proyek di tingkat ruang nama rpm dari proyek ke compat-project-x untuk memungkinkan membedakan antara versi yang tidak kompatibel dari jalur impor yang sama, persis seperti yang akan dilakukan vgo).
• trik ini sangat berguna dalam membantu proyek Go yang kompleks dibangun
• meskipun tidak selengkap dan sekuat melakukannya di tingkat bahasa
• kami lebih suka menyampaikan batasan bahasa ke rpm/dnf daripada menambahkan overlay batasan rpm/dnf di atas kode asli.
• kami cukup muak dengan semua solusi sistem file yang saat ini diperlukan untuk meyakinkan alat go untuk melihat sumber proyek Go. GOPATH fisik tidak akan terlewatkan sama sekali.

Oleh karena itu kami sangat senang dengan vgo dan berharap itu akan segera diterapkan (kami membutuhkannya bertahun-tahun yang lalu).

Meskipun demikian, penggunaan alur kerja seperti vgo kami mengungkapkan kesulitan berikut.

Proposal vgo memberi selamat pada dirinya sendiri karena telah membuat makefile tidak diperlukan. Ini tidak sepenuhnya benar.

• banyak proyek Go yang jatuh cinta dengan file go yang dibuat secara otomatis dan tidak ada cara standar dalam permintaan untuk membuat ulang file tersebut atau untuk mengungkapkan apa yang dibutuhkan generasi agar berhasil
• sangat buruk sehingga banyak proyek harus dikirimkan dengan file yang dibuat sebelumnya (kadang-kadang membuat repositori file yang dibuat sebelumnya secara terpisah)
• file-file itu adalah sumber besar ketidakcocokan versi. Manusia berhati-hati untuk menulis kode yang tidak perlu diubah setiap hari saat terkena versi ketergantungan baru. File yang dibuat secara otomatis OTOH sering kali terkait erat dengan lingkungan pembuatan yang tepat, karena pembuat alat pembuat menganggap Anda hanya akan membuat ulang sesuai kebutuhan.
• agar vgo berhasil, diperlukan cara untuk mengidentifikasi file-file itu, menghapusnya dari modul .zip, dan mengungkapkan cara membuatnya kembali ke pengguna modul .zip

Ini diperparah dengan aturan "semuanya harus ada di GOPATH" saat ini

• semuanya tidak bisa di GOPATH ketika generasi bergantung pada file proto yang diterbitkan di luar GOPATH oleh proyek multi-bahasa
• toolchain Go perlu belajar membaca sumber daya di luar GOPATH
• toolchain Go perlu belajar untuk memublikasikan sumber daya di luar GOPATH, ketika mereka terpapar ke proyek yang belum tentu ditulis dalam Go
• solusi saat ini untuk menduplikasi sumber daya dalam salinan di dalam GOPATH adalah sumber lain dari versi yang tidak kompatibel
• semua orang tidak akan menyalin file yang sama secara bersamaan
• terkadang proyek menyalin dari beberapa sumber, menciptakan campuran yang unik.
• setiap proyek akan QA pada salinannya sendiri, membuat komposisi proyek Go berbahaya
• pemecah versi vgo tidak akan berfungsi sebagaimana dimaksud jika menghitung hubungan antara rilis kode tetapi mengabaikan hubungan antara rilis sumber daya.
• vgo perlu membuat salinan pribadi dari hal-hal yang dipublikasikan di luar GOPATH yang tidak perlu untuk menghindari ledakan versi modul yang tidak kompatibel.

Banyak proyek telah mengeksploitasi aturan "setiap direktori Go adalah paket terpisah" untuk menerbitkan proyek dengan kode yang tidak kompatibel, atau benar-benar rusak di subdirektori terpisah

• banyak proyek Go lainnya telah menggunakan aturan yang sama untuk memilih subdirektori tertentu dan menggunakannya dalam konteks yang tidak kompatibel dengan pengujian unit proyek asli dan QA
• yang "berfungsi" dan menghasilkan "bangunan yang dapat direproduksi" selama tidak ada perubahan dalam proyek asli atau dalam proyek, konsumen menggunakan beberapa bagian lain dari proyek asli. Ketika itu terjadi, seluruh istana pasir runtuh di bawah akumulasi hutang teknis,
• Anda melihat proyek menolak untuk memperbarui ke versi proyek yang lebih baru karena itu memerlukan pembersihan penyalahgunaan proyek lain sebelumnya.
• Anda memiliki skizofrenia aneh di mana proyek Go menganggap diri mereka tidak bertanggung jawab atas bug di basis kode yang mereka gunakan kembali, dan pada saat yang sama menolak untuk menerapkan perbaikan yang diterbitkan oleh basis kode yang sama (saya kira kita semua manusia dan penolakan kenyataan yang tidak menyenangkan sudah tertanam di otak manusia)
• perbaikan tidak menyebar, dan semuanya "baik-baik saja" sampai Anda menemukan bug yang membutuhkan perbaikan di tempat pertama atau tes unit yang dibatalkan oleh pemetikan ceri.
• pemeriksa keamanan otomatis yang membandingkan status keamanan proyek, dengan status keamanan proyek yang sama di dalam direktori vendor, akan memiliki hari lapangan
• semakin besar proyeknya, semakin besar kemungkinannya untuk memiliki bom yang terus berdetak seperti itu tersembunyi di dalam vendornya
• dengan mendefinisikan dengan jelas batasan proyek di dalam modul zip, vgo akan mengakhiri praktik semacam itu
• namun itu juga akan memerlukan pembersihan besar-besaran dari banyak basis kode Go
• agar vgo berhasil, ia perlu menyediakan alat untuk membantu memfaktorkan ulang proyek Go yang ada dan membagi basis kodenya dalam modul yang masuk akal dari sudut pandang kompatibilitas perangkat lunak. Jika tidak, proyek yang menggunakan vgo akan menghasilkan batasan yang tidak dapat didamaikan atau hanya mengunci status quo (yang berfungsi untuk kode yang ada, tetapi mengerikan dari sudut pandang evolusi kode).

Praktik saat ini mengekspos seluruh basis kode Go dalam satu pohon GOPATH dengan sedikit batasan antar proyek telah menghasilkan efek samping yang merusak dari POW rekayasa perangkat lunak

• kode tidak dilakukan dalam proyek yang masuk akal secara teknis tetapi dalam repo yang paling nyaman untuk pembuat kode (repo tempat ia memiliki akses)
• Proyek Go berdarah satu sama lain, dengan bagian dari satu proyek tergantung pada bagian dari proyek lain, dan bagian dari proyek lain ini tergantung pada proyek aslinya
• yang secara efektif menghasilkan grafik kendala versi terkunci di mana Anda tidak dapat memindahkan satu bagian tanpa memindahkan semua yang lain
• tidak ada yang memiliki sumber daya untuk mengubah semua yang lain dalam satu operasi
• proyek menemui jalan buntu dan berhenti berkembang
• menggunakan modul dengan batasan yang jelas dan mencoba membuat batasan versi antar-modul secara eksplisit akan mengekspos situasi tersebut
• yang akan sangat tidak populer (meskipun masalahnya ada hari ini, tersembunyi di balik tabir penjaja)
• cukup sering ini bukan hanya masalah memisahkan subdirektori: masalah dependensi proyek dapat terjadi di pohon direktori A/B/C/D pada level A dan D tetapi tidak pada B dan C.
• agar vgo berhasil, vgo perlu menyediakan alat untuk membantu memfaktorkan ulang proyek Go yang ada dan membagi basis kodenya dalam modul terpisah yang mengikuti garis grafik ketergantungan

Testfing/fixtures, contoh dan testdata adalah kaleng worm lainnya, dengan kebutuhan versi ketergantungan dan ketergantungannya sendiri

• mereka perlu diisolasi dengan satu atau lain cara dalam modul terpisah atau kebutuhan mereka akan meracuni resolusi versi solver
• jika Anda mengabaikan kebutuhan mereka, Anda secara efektif tidak memutuskan siapa pun kecuali proyek asli yang akan menjalankan tes unit
• ini cukup berbahaya ketika Anda mengizinkan peningkatan versi. Masalah akan terjadi. Anda perlu mendeteksi mereka
• tes integrasi yang tidak hanya bergantung pada beberapa kode lain, tetapi lingkungan tertentu yang tidak dapat direplikasi oleh siapa pun kecuali proyek asli (misalnya, server atau situs web tertentu untuk diajak bicara), mungkin memerlukan isolasi khusus

Saya mungkin telah melupakan lebih banyak hal, tetapi itu adalah yang paling penting.

Akhirnya:

• Proyek Go tidak hidup dalam isolasi
• beberapa proyek Go menerbitkan konektor ke bahasa lain
• beberapa proyek dalam bahasa lain menerbitkan konektor Go
• itu membuat memperlakukan semver dengan cara yang berbeda seperti bahasa-bahasa lain itu menjadi masalah.
• Anda tidak dapat memiliki semuanya kecuali bagian Go memperbarui ke versi minor terbaru saat proyek multi-bahasa dirilis.
• itu akan menjadi neraka dari POW manajemen operasional.
• pemutakhiran otomatis ke subrilis terbaru memainkan peran besar dalam menyederhanakan grafik batasan perangkat lunak dengan membuat semua orang mengosongkan versi yang lebih lama (manfaatnya bersifat teknis, mekanismenya bersifat sosial).
• pembuatan ulang fidelitas tinggi mirip dengan situs web dengan piksel sempurna. Mereka terlihat seperti ide yang jelas bagus, mereka menghargai ego penulis asli, tetapi mereka adalah PITA bagi siapa saja yang benar-benar mencoba menggunakan hasilnya karena mereka tidak dapat berevolusi dan beradaptasi dengan konteks lokal (bukan asli).

Di server proxy:

untuk debugging yang mudah, $GOPROXY bahkan dapat berupa file:/// URL yang menunjuk ke pohon lokal.

Harap buat ini berfungsi dengan file:/// dari https:/// URL yang menunjuk ke direktori yang berisi modul pihak ketiga dalam bentuk zip (dan kecualikan yang lainnya)

Itu adalah cara paling sederhana bagi entitas untuk mengoordinasikan pekerjaan beberapa tim pengembangan yang mengandalkan subset dari daftar proyek pihak ketiga yang sama: memiliki petugas QA/hukum/keamanan yang bertanggung jawab untuk memeriksa rilis pihak ketiga yang "baik" dan menerapkannya dalam direktori umum dan minta orang lain memiliki pekerjaan mereka bergantung pada modul yang tersedia di direktori umum ini.

Dengan begitu Anda yakin tidak ada yang mulai mengerjakan putaran yang tidak sesuai dengan pekerjaan orang lain, dan tidak ada yang tetap berada di putaran kereta atau berbahaya yang sudah diidentifikasi oleh tim lain, dan stasiun pengembang Anda tidak terus-menerus menunggu unduhan salinan yang sama perangkat lunak yang sudah tersedia secara lokal.

@Merovius Saya tidak setuju, tetapi saya pikir kami menyimpang dari topik dan tidak ingin menghentikan diskusi masalah. Saya senang untuk menindaklanjuti dalam media yang berbeda, namun. (Email saya ada di profil github saya dan saya joeshaw di slack Gophers.)

https://github.com/golang/go/issues/24301#issuecomment -374882685, @tpng :

Zona waktu mana yang digunakan untuk stempel waktu dalam versi semu (v0.0.0-yyyymmddhhmmss-commit)?

Seperti yang Anda catat dalam suntingan Anda, UTC. Tetapi perhatikan juga bahwa Anda tidak perlu mengetiknya. Anda cukup mengetikkan git commit hash (awalan) dan vgo akan menghitung dan mengganti versi semu yang benar.

https://github.com/golang/go/issues/24301#issuecomment -374907338, @AlexRouSg :

Apakah Anda akan menangani dependensi C?

https://github.com/golang/go/issues/24301#issuecomment -376606788, @stevvooe :

apa yang akan terjadi dengan sumber daya non-Go, seperti protobuf atau file c?

https://github.com/golang/go/issues/24301#issuecomment -377186949, @nim-nim:

Proposal vgo memberi selamat pada dirinya sendiri karena telah membuat makefile tidak diperlukan. Ini tidak sepenuhnya benar. [Diskusi tentang kode yang dihasilkan.]

Pengembangan Non-Go terus menjadi non-tujuan dari perintah go , jadi tidak akan ada dukungan untuk mengelola pustaka C dan semacamnya, juga tidak akan ada dukungan eksplisit untuk buffering protokol.

Meskipun demikian, kami tentu memahami bahwa menggunakan buffering protokol dengan Go terlalu sulit, dan kami ingin agar hal itu ditangani secara terpisah.

Untuk kode yang dihasilkan secara lebih umum, sistem pembangunan lintas bahasa yang sebenarnya adalah jawabannya, khususnya karena kami tidak ingin setiap pengguna harus menginstal generator yang tepat. Lebih baik bagi penulis untuk menjalankan generator dan memeriksa hasilnya.

https://github.com/golang/go/issues/24301#issuecomment -375248753, @mrkanister :

Saya tahu bahwa cabang default dapat diubah dari master ke v2, tetapi ini masih memberi saya tugas untuk memperbaruinya setiap kali saya merilis versi utama yang baru. Secara pribadi, saya lebih suka memiliki master dan cabang v1, tetapi saya tidak yakin bagaimana tepatnya ini akan sesuai dengan proposal.

Seperti yang ditunjukkan oleh @AlexRouSg dan mungkin orang lain, Anda dapat melakukan ini. Saya hanya ingin mengkonfirmasi jawaban mereka. Saya juga akan menambahkan ini ke FAQ.

https://github.com/golang/go/issues/24301#issuecomment -375989173, @aarondl :

Meskipun ini berfungsi sekarang, apakah ini dimaksudkan?

Pastinya ya.

@jamiethermo , terima kasih banyak untuk komentar tentang Perforce dan cabang di direktori yang berbeda. Saya lupa tentang fitur itu, tapi mungkin itulah yang meyakinkan saya bahwa penting untuk mengizinkan di vgo.

Ada diskusi yang bagus mulai dari https://github.com/golang/go/issues/24301#issuecomment -376925845 tentang vendor versus proxy. Jelas ada dua set keprihatinan yang berbeda di sini.

Pengembang open source cenderung ingin menghindari ketergantungan pada infrastruktur, sehingga mereka menginginkan vendor, seperti yang ditulis @joeshaw . Untuk mengonfirmasi, kami akan membuatnya tetap berfungsi, dalam bentuk terbatas (hanya direktori vendor di tingkat teratas dari keseluruhan modul target tempat Anda menjalankan perintah go).

Pengembang perusahaan tidak memiliki masalah mengandalkan infrastruktur - itu hanya biaya lain - terutama jika itu membawa pengurangan biaya yang lebih besar, seperti tidak menduplikasi semua kode vendor mereka di setiap repo dan harus meluangkan waktu untuk menjaga semuanya tetap sinkron. Pada dasarnya setiap perusahaan yang kami ajak bicara menginginkan proxy/mirror, bukan vendor, seperti yang diminta @jamiethermo . Kami akan memastikan itu berhasil juga.

Kami juga sangat ingin membangun jaringan cermin bersama yang memiliki alasan untuk dipercaya dan diandalkan oleh para pengembang, sehingga semua pengembang sumber terbuka tidak akan merasa bahwa mereka harus menjadi vendor. Tapi itu nanti. Vgo pertama harus menjadi go.

https://github.com/golang/go/issues/24301#issuecomment -377220411, @nim-nim:

Harap buat ini berfungsi dengan file:/// dari https:/// URL yang menunjuk ke direktori yang berisi modul pihak ketiga dalam bentuk zip (dan kecualikan yang lainnya)

Saya tidak yakin apa yang Anda minta dengan mengatakan "kecualikan yang lainnya". Jika $GOPROXY disetel, vgo meminta proxy itu. Itu tidak pernah jatuh kembali ke tempat lain. Proksi itu dapat dilayani oleh pohon file statis, yang sebagian besar merupakan modul pihak ketiga dalam bentuk zip. Pohon file juga harus berisi beberapa file metadata lainnya, untuk navigasi dan pencarian. File tambahan tersebut tidak dapat dihindari, karena HTTP tidak memberi kita cara standar untuk melakukan hal-hal seperti daftar direktori.

https://github.com/golang/go/issues/24301#issuecomment -377186949, @nim-nim:

Wah panjang sekali komentarnya. Saya pikir saya setuju dengan sebagian besar dari apa yang Anda tulis. Saya ingin menanggapi butir terakhir di pos Anda:

• pembuatan ulang fidelitas tinggi mirip dengan situs web dengan piksel sempurna. Mereka terlihat seperti ide yang jelas bagus, mereka menghargai ego penulis asli, tetapi mereka adalah PITA bagi siapa saja yang benar-benar mencoba menggunakan hasilnya karena mereka tidak dapat berevolusi dan beradaptasi dengan konteks lokal (bukan asli).

Saya pikir saya akan berpendapat bahwa file kunci seperti situs web dengan piksel sempurna. Sebaliknya, build dengan fidelitas tinggi menurun dengan anggun saat konteks berubah. Secara default, build akan menggunakan, katakanlah, B 1.2 dan C 1.4. Tetapi kemudian jika itu adalah bagian dari bangunan yang lebih besar yang membutuhkan B 1.3, baiklah, itu akan cocok dengan B 1.3 tetapi tetap menggunakan C 1.4 (bahkan jika yang lebih baru ada) jika tidak ada persyaratan konkret untuk meningkatkan. Jadi benar-benar build dengan fidelitas tinggi adalah yang terbaik dari kedua dunia: setia pada aslinya sejauh mungkin, tetapi tidak memaksakan piksel-sempurna ketika itu tidak memungkinkan.

https://github.com/golang/go/issues/24301#issuecomment -375415904, @flibustenet :

@rsc Saya ingin meminta Anda untuk lebih tepat tentang peta jalan dan apa yang harus kita lakukan sekarang.
Apakah akan mengikuti kebijakan Go dan fitur freeze vgo pada 3 bulan (2 sekarang) ?

Vgo adalah prototipe dan tidak akan pernah dirilis sendiri. Itu tidak tunduk pada pembekuan atau apa pun. Tetapi proposal ini adalah untuk memindahkan ide dan sebagian besar kode ke cmd/go utama. Sebagai bagian dari rilis, cmd/go tentu saja akan dibekukan. Karena itu ikut serta dan karena kode khusus vgo cukup terisolasi dengan baik dari sisa operasi perintah go, bekerja pada bagian khusus vgo memiliki risiko yang cukup rendah dan saya dapat melihatnya berlanjut selama beberapa minggu ke dalam pembekuan. Saat ini saya sedang fokus pada pembahasan dan penyesuaian proposal. Setelah proposal tampak dalam kondisi yang baik tanpa masalah yang berarti, maka kita akan beralih ke pemindahan kode ke cmd/go.

Haruskah kita sekarang pergi dengan tongkat peziarah kita meminta setiap pengelola libs untuk menambahkan file go.mod atau haruskah kita menunggu proposal diterima secara resmi (untuk memastikan bahwa nama dan sintaks tidak akan berubah)?

Saya pikir sintaks go.mod kemungkinan akan berubah (perhatikan masalah ini). Tapi seperti yang saya sebutkan di proposal, kami akan tetap menerima sintaks lama selamanya, dan vgo hanya akan memperbarui file yang ada, jadi itu bukan masalah besar. Yang mengatakan, saya tidak akan mencoba mengirim PR ke setiap perpustakaan yang dapat Anda temukan sampai kode tersebut mendarat di salinan pengembangan cmd/go.

https://github.com/golang/go/issues/24301#issuecomment -376640804, @pbx0 :

apakah mudah (hari ini) dengan vgo untuk menentukan apakah Anda memiliki lebih dari 1 versi paket dalam sebuah build?

Hal termudah untuk dilakukan hari ini adalah membangun biner dan kemudian menjalankan goversion -m di atasnya (lihat https://research.swtch.com/vgo-repro). Ketika kita memiliki daftar go sadar modul yang lebih umum, seharusnya dapat melakukan hal yang sama tanpa membangun biner terlebih dahulu.

https://github.com/golang/go/issues/24301#issuecomment -376236546, @buro9 :

[Dapatkah saya membuat perubahan keamanan yang tidak kompatibel, seperti microcosm-cc/ bluemonday@a5d7ef6? ]

Seperti yang dikatakan @Merovius , jika kita mengadopsi pedoman kompatibilitas Go 1 maka perubahan keamanan secara eksplisit diperbolehkan tanpa menabrak versi utama.

Meskipun demikian, bahkan ketika Anda harus melakukan sesuatu untuk keamanan, Anda mungkin masih harus berusaha untuk meminimalkan gangguan. Komit yang Anda tautkan bisa dibilang lebih mengganggu daripada yang diperlukan, dan dalam situasi masa depan saya akan mendorong Anda untuk mendekati perubahan seperti itu dari sudut pandang "bagaimana cara memecahkan klien sesedikit mungkin sambil tetap menghilangkan masalah keamanan? "

Misalnya, jangan hapus fungsi. Sebaliknya, buat fungsi panik atau log. Fatal hanya jika dipanggil dengan tidak benar.

Dalam hal ini, alih-alih menghapus AllowDocType, saya akan menyimpannya dan tentu saja terus menerima AllowDocType(false), karena itulah pengaturan yang aman. Jika seseorang telah menulis pembungkus untuk perpustakaan Anda, mungkin sebagai program baris perintah dengan tanda -allowdoctype, maka setidaknya penggunaan program tanpa tanda itu akan terus berfungsi.

Dan kemudian di luar itu, sepertinya kekhawatirannya adalah bahwa doctype benar-benar tidak dicentang, tetapi saya mungkin akan melakukan pemeriksaan minimal untuk menjaga penggunaan yang paling umum berfungsi, dan kemudian secara konservatif menolak yang lain. Misalnya, setidaknya, saya akan terus mengizinkan dan mungkin juga repot mengizinkan ..> dengan string yang dikutip tanpa karakter &#<>\.

https://github.com/golang/go/issues/24301#issuecomment -375090551, @TocarIP :

[Kekhawatiran tentang tidak segera mendapatkan pembaruan.]

Saya benar-benar berpikir yang sebaliknya akan terjadi, bahwa program mungkin lebih mutakhir, karena dalam pemilihan versi minimal _tidak mungkin_ untuk satu ketergantungan untuk mencegah keseluruhan pembangunan memperbarui ke versi yang lebih baru.

Apa yang ditulis @Merovius di https://github.com/golang/go/issues/24301#issuecomment -375992900 terdengar sangat tepat bagi saya. Poin utamanya adalah Anda hanya mendapatkan pembaruan saat Anda memintanya, jadi hal-hal (berpotensi) rusak hanya saat Anda mengharapkannya dan siap untuk menguji, men-debug, dan sebagainya. Anda memang harus memintanya, tetapi tidak secara signifikan lebih sering daripada di sistem lain dengan file kunci. Dan kami juga ingin mempermudah memunculkan peringatan seperti "Anda sedang membangun dengan versi yang tidak digunakan lagi/tidak aman". Tetapi penting untuk tidak hanya memperbarui secara diam-diam sebagai efek samping dari operasi non-pembaruan.

Juga ditambahkan ke FAQ.

Terima kasih kepada semua orang untuk diskusi hebat sejauh ini dan untuk menjawab pertanyaan satu sama lain. Jawaban yang sangat bagus dari banyak orang, tetapi terima kasih khusus kepada @Merovius dan @kardianos. Saya telah memperbarui FAQ https://github.com/golang/go/issues/24301#issuecomment -371228664 dan Ringkasan Diskusi https://github.com/golang/go/issues/24301#issuecomment -371228742. Ada tiga pertanyaan penting yang belum terjawab (mereka mengatakan TODO dalam ringkasan), yang akan saya kerjakan selanjutnya. :-)

@rsc , #24057 memiliki beberapa diskusi tentang penggunaan tar alih-alih Zip.

https://github.com/golang/go/issues/24301#issuecomment -375106068, @leonklingele :

Jika dukungan untuk go get seperti yang kita kenal sekarang akan ditinggalkan dan pada akhirnya dihapus, lalu apa cara yang disarankan untuk mengambil & menginstal (tidak ditandai) Go binari?

Itu masih akan pergi dapatkan. Jika repo biner tidak ditandai, go get akan menggunakan komit terbaru. Tetapi sebenarnya orang yang menerbitkan binari harus didorong untuk menandai repo yang berisi sama dengan repo yang berisi perpustakaan (atau campuran).

Jika $GOPATH tidak digunakan lagi, di mana binari ini akan dipasang?

Anda tidak perlu bekerja di $GOPATH lagi, tetapi kode masih ditulis ke direktori pertama yang terdaftar di $GOPATH - ini adalah cache sumber, lihat $GOPATH/src/v setelah menggunakan vgo. Binari diinstal ke $GOPATH/bin. Pada beberapa rilis yang lalu Anda tidak perlu menyetel $GOPATH - ia memiliki default, $HOME/go. Jadi yang seharusnya terjadi adalah pengembang berhenti mencemaskan pengaturan $GOPATH atau bahkan mengetahui apa itu, dan mereka baru mengetahui bahwa binari mereka ada di $HOME/go/bin. Mereka dapat menggunakan $GOBIN untuk mengganti lokasi tersebut.

@dsnet , terima kasih saya menambahkan tautan di ringkasan diskusi. Mari kita lanjutkan diskusi itu di sana.

Jika $GOPROXY disetel, vgo meminta proxy itu. Itu tidak pernah jatuh kembali ke tempat lain. Proksi itu dapat dilayani oleh pohon file statis, yang sebagian besar merupakan modul pihak ketiga dalam bentuk zip. Pohon file juga harus berisi beberapa file metadata lainnya, untuk navigasi dan pencarian. File tambahan tersebut tidak dapat dihindari, karena HTTP tidak memberi kita cara standar untuk melakukan hal-hal seperti daftar direktori.

Selama modul asli disimpan dalam bentuk zip, menghilangkan godaan untuk mengutak-atiknya, dan pengindeksnya kuat dan ringan, tidak apa-apa.

Meskipun batasan daftar tidak berlaku untuk file dan utilitas seperti lftp telah dapat membuat daftar direktori http untuk waktu yang lama (tidak masalah jika itu non-standar jika berfungsi pada server http utama). Jadi operasi tanpa indeks mungkin dan lebih disukai untuk entitas kecil yang tidak ingin berinvestasi di infra. yum/dnf/zipper juga bergantung pada indeks khusus dan membuat direktori bersama yang diindeks tidak selalu sesederhana yang mungkin Anda pikirkan di beberapa organisasi.

Pengembang open source cenderung ingin menghindari ketergantungan pada infrastruktur, sehingga mereka menginginkan vendor, seperti yang ditulis @joeshaw

Tidak juga, sebagian besar pengembang open source ingin seluruh proses terbuka dan transparan, dan tidak harus bergantung pada keinginan baik orang lain. Jadi infra baik-baik saja selama itu sendiri open source dan mudah dan murah untuk digunakan secara lokal. Mengandalkan situs berpemilik blackbox besar seperti github jelas tidak termasuk dalam kategori ini, tetapi itu tidak sama dengan infra. Orang-orang open source melakukan mirror beberapa dekade sebelum orang lain. Apa yang tidak akan mereka terima adalah tertutup dan mahal untuk memasang mirror (dalam istilah open source mahal diukur dalam waktu manusia)

Sifat vendoring yang mudah dan murah sangat dihargai, proses vendoring itu sendiri dan caranya mendorong fosilisasi basis kode yang progresif pada versi kode pihak ketiga yang sudah usang, tidak terlalu banyak.

Pengembang perusahaan tidak memiliki masalah dalam mengandalkan infrastruktur - itu hanya biaya tambahan

Pasti sangat menyenangkan bekerja di Google :(. Kecuali untuk beberapa Perusahaan dengan operasi Go besar yang ada di mana berinvestasi di infra Go adalah hal yang mudah, semua orang harus melalui proses persetujuan yang panjang dan membosankan , jika hanya untuk membenarkan membayar seseorang untuk melihat masalahnya. Jadi, biaya infra apa pun akan mengurangi jangkauan Go dan mencegah adopsinya oleh struktur baru.

Entreprise seperti opensourcer, mereka peduli dengan murah dan mudah. Mereka dulu tidak peduli sama sekali tentang terbuka, tapi itu perlahan berubah sekarang karena mereka menyadari itu berkorelasi dengan murah (dengan cemas pemasok Perusahaan tradisional yang dulu mengkhususkan diri pada solusi blackbox mahal dengan konsultasi mahal untuk membantu penyebaran).

Perusahaan yang mengontrakkan TI internal ke penawar terendah pasti akan bersikeras pada cermin karena mereka pasti tidak ingin pengembang murahan mereka mengunduh kode yang rusak atau berbahaya yang tidak dipahami oleh para pengembang dari Internet. Mereka akan membayar manusia dan alat untuk memindai konten cermin lokal untuk masalah, dan memaksa TI internal untuk menggunakannya secara eksklusif.

Kami juga sangat ingin membangun jaringan cermin bersama yang memiliki alasan untuk dipercaya dan diandalkan oleh para pengembang, sehingga semua pengembang sumber terbuka tidak akan merasa bahwa mereka harus menjadi vendor.

Cukup publikasikan salinan referensi dari direktori terindeks yang berisi modul di suatu tempat. Lupakan pengaturan seperti proxy yang memerlukan konfigurasi server web tertentu. Itulah yang dilakukan oleh open source dan mereka tidak mengalami kesulitan untuk mencerminkan diri mereka sendiri. Selama mirroring hanya menyalin konten direktori dan tidak memerlukan konfigurasi server web tertentu, ada banyak organisasi yang bersedia untuk melakukan mirror.

Adapun kode yang dihasilkan secara lebih umum, sistem pembangunan lintas bahasa yang nyata adalah jawabannya,

Anda tahu dan juga saya bahwa itu tidak akan pernah terjadi, seseorang akan selalu ingin menemukan bahasa baru yang melakukan tugasnya sendiri. Itu argumen strawman.

Itu tidak mencegah Go menormalkan perintah standar yang meluncurkan proses spesifik proyek apa pun yang menghasilkan kode, dengan pedoman ketat tentang apa yang bisa dan tidak bisa dilakukan (biasanya tidak boleh melakukan apa pun yang sudah dicakup oleh perintah Go standar, karena perintah itu harus sudah baik-baik saja).

khususnya karena kami tidak ingin setiap pengguna perlu memasang generator yang tepat. Lebih baik bagi penulis untuk menjalankan generator dan memeriksa hasilnya.

Itu akan membutuhkan pemikiran ulang besar-besaran tentang bagaimana generator yang ada diimplementasikan, karena saat ini mereka tidak peduli sama sekali tentang portabilitas versi dan mengharapkan lingkungan perangkat lunak dibekukan sebelum generasi. Dengan efek langsung yang dihasilkan membuat perubahan versi yang lebih baru tanpa regenerasi berbahaya. Tidak masalah jika hasilnya diperiksa oleh manusia atau tidak karena manusia hanya akan memeriksa set versi aslinya. vgo bergantung pada kemampuan untuk melakukan perubahan versi yang lebih baru.

Jadi vgo harus menangani regenerasi cepat atau lambat. Nanti berarti menunggu proyek untuk mengetahui bahwa pembaruan vgo berbahaya dengan adanya kode yang dihasilkan.

https://github.com/golang/go/issues/24301#issuecomment -374791885, @jimmyfrasche :

Ini juga akan mempengaruhi hal-hal seperti driver database dan format gambar yang mendaftarkan diri dengan paket lain selama init, karena beberapa versi utama dari paket yang sama dapat melakukan hal ini. Tidak jelas bagi saya apa akibat dari semua itu.

Ya, masalah kode yang mengasumsikan "hanya akan ada satu dari ini dalam sebuah program" adalah nyata, dan itu adalah sesuatu yang kita semua harus selesaikan untuk membangun praktik dan konvensi terbaik baru (lebih baik). Saya tidak berpikir masalah ini diperkenalkan oleh vgo, dan vgo bisa dibilang membuat situasi lebih baik dari sebelumnya.

Saya mengerti bahwa beberapa orang berpendapat bahwa vgo harus mengadopsi aturan Dep bahwa bahkan tidak boleh ada 1.x dan 2.x bersama-sama, tetapi itu sangat jelas tidak menskalakan ke basis kode besar yang kami targetkan dengan Go. Tidak mungkin mengharapkan seluruh program besar untuk meningkatkan dari satu API ke API lainnya sekaligus, seperti yang ditunjukkan oleh posting vgo-import . Saya percaya pada dasarnya semua manajer paket lainnya mengizinkan 1.x dan 2.x bersama-sama untuk alasan yang sama. Tentu saja Kargo melakukannya.

Secara umum vgo memang mengurangi duplikasi dibandingkan dengan vendoring. Dengan vendoring, mudah untuk mendapatkan 1.2, 1.3, dan 1.4 dari paket yang diberikan semua dalam satu biner, tanpa menyadarinya, atau bahkan mungkin tiga salinan dari 1.2. Setidaknya vgo memotong kemungkinan duplikasi menjadi satu 1.x, satu 2.x, dan seterusnya.

Sudah menjadi kasus bahwa penulis paket yang berbeda perlu memastikan untuk tidak mencoba mendaftarkan hal yang sama. Misalnya, expvar melakukan http.Handle("/debug/vars") dan pada dasarnya mempertaruhkan klaim ke jalur itu. Saya harap kita semua setuju bahwa paket pihak ketiga seperti awesome.io/supervars tidak boleh mencoba mendaftarkan jalur yang sama. Itu meninggalkan konflik antara beberapa versi dari satu paket.

Jika kami memperkenalkan expvar/v2, maka itu akan menjadi paket kedua yang berbeda, seperti awesome.io/supervars, dan mungkin bertentangan dengan expvar dalam build besar. Tidak seperti supervars, expvar/v2 dimiliki oleh orang atau tim yang sama dengan expvar, sehingga kedua paket dapat berkoordinasi untuk berbagi pendaftaran. Itu akan bekerja sebagai berikut. Misalkan expvar v1.5.0 adalah yang terakhir sebelum kita memutuskan untuk menulis v2, jadi v1.5.0 memiliki http.Handle di dalamnya. Kami ingin v2 menjadi pengganti v1, jadi kami akan memindahkan http.Handle ke v2.0.0 dan menambahkan API di v2 yang memungkinkan v1 meneruskan panggilannya ke v2. Kemudian kita akan membuat v1.6.0 yang diimplementasikan dengan penerusan ini. v1.6.0 tidak memanggil http.Handle; itu mendelegasikan itu ke v2.0.0. Sekarang expvar v1.6.0 dan expvar/v2 dapat hidup berdampingan, karena kami merencanakannya seperti itu. Satu-satunya masalah yang tersisa adalah apa yang terjadi jika build menggunakan expvar v1.5.0 dengan expvar/v2? Kita perlu memastikan itu tidak terjadi. Kami melakukannya dengan membuat expvar/v2 membutuhkan expvar di v1.6.0 (atau lebih baru), meskipun tidak ada impor ke arah itu, dan tentu saja expvar v1.6.0 juga membutuhkan expvar/v2 di v2.0.0 atau lebih baru untuk memanggil API-nya . Siklus persyaratan ini memungkinkan kami memastikan bahwa v1.5.0 dan v2 tidak pernah tercampur. Perencanaan untuk jenis koordinasi lintas-versi mayor ini adalah alasan mengapa pemilihan versi minimal memungkinkan siklus dalam grafik persyaratan.

Aturan "hanya satu versi utama" yang dikombinasikan dengan mengizinkan siklus dalam grafik persyaratan memberi penulis alat yang mereka butuhkan untuk mengelola koordinasi lajang yang tepat (dan migrasi kepemilikan lajang) antara versi utama yang berbeda dari modul mereka. Kami tidak dapat menghilangkan masalah, tetapi kami dapat memberi penulis alat yang mereka butuhkan untuk menyelesaikannya.

Saya tahu bahwa buffer protokol khususnya memiliki masalah pendaftaran, dan masalah itu diperburuk oleh cara khusus file .pb.go protokol diedarkan dan disalin ke dalam proyek. Itu lagi sesuatu yang sebagian besar independen dari vgo. Kita harus memperbaikinya, tetapi mungkin dengan membuat perubahan pada cara buffer protokol Go digunakan, bukan vgo.

https://github.com/golang/go/issues/24301#issuecomment -374739116, @ChrisHines :

Saya paling khawatir tentang jalur migrasi antara dunia pra-vgo dan dunia vgo menjadi buruk. [lebih detail]

Saya sangat senang ini adalah komentar pertama pada proposal. Ini jelas hal yang paling penting untuk mendapatkan yang benar.

Transisi dari go get lama dan berbagai alat vendor ke sistem modul baru harus berjalan sangat lancar. Saya telah banyak berpikir baru-baru ini tentang bagaimana tepatnya itu akan berhasil.

Proposal asli memungkinkan pengembang opsi untuk menempatkan versi 2 modul di subdirektori repo bernama v2/. Menjalankan opsi itu akan memungkinkan pengembang untuk membuat repo yang menggunakan versi impor semantik, kompatibel dengan modul, namun juga kompatibel dengan "go get" lama. Posting yang menjelaskan opsi ini mengakui bahwa sebagian besar proyek tidak ingin menggunakan opsi ini, itu tidak masalah. Ini hanya diperlukan untuk kompatibilitas jika proyek sudah di v2 atau lebih baru. Pada saat yang sama, saya meremehkan jumlah proyek besar yang digunakan secara luas yang berada di v2 atau lebih baru. Sebagai contoh:

• github.com/godbus/dbus ada di v4.1.0 (diimpor oleh 462 paket).
• github.com/coreos/etcd/clientv3 ada di v3.3.3 (diimpor oleh 799 paket).
• k8s.io/client-go/kubernetes ada di v6.0.0 (diimpor oleh 1928 paket).

Untuk menghindari kerusakan klien mereka, proyek-proyek tersebut perlu dipindahkan ke subdirektori sampai semua klien dapat diasumsikan menggunakan modul, dan kemudian pindah kembali ke root. Itu banyak untuk ditanyakan.

Pilihan lain untuk bermain trik dengan submodul git. Perintah go get yang lama lebih menyukai tag atau cabang bernama "go1" daripada cabang default repo, sehingga proyek yang ingin mengaktifkan transisi yang mulus dapat membuat komit pada cabang "go1" yang hanya memiliki subdirektori "v2" yang disiapkan sebagai submodule git yang menunjuk kembali ke root repo yang sebenarnya. Ketika "go get" memeriksa cabang go1 itu dan submodul yang terisi, itu akan mendapatkan tata letak pohon file yang tepat. Itu agak buruk, dan pointer submodule perlu diperbarui setiap kali rilis baru dibuat.

Kedua hal ini memiliki efek yang tidak menguntungkan sehingga penulis harus mengambil langkah-langkah untuk menghindari pelanggaran pengguna mereka, dan itupun hanya untuk rilis baru. Kami ingin kode pengguna tetap bekerja bahkan tanpa pekerjaan tambahan oleh penulis, dan idealnya bahkan untuk rilis lama.

Tapi itu adalah satu-satunya cara yang dapat saya pikirkan untuk tetap tidak dimodifikasi, yang lama mulai bekerja saat kita beralih ke dunia modul. Jika bukan itu, maka alternatifnya adalah memodifikasi go get lama, yang sebenarnya berarti memodifikasi go build lama.

Pada dasarnya, ada dua konvensi jalur impor yang berbeda: yang lama, tanpa versi utama, dan yang baru, dengan versi utama di v2 atau lebih baru. Kode di pohon lama mungkin menggunakan konvensi lama, sedangkan kode di pohon baru - di bawah direktori yang berisi file go.mod - mungkin menggunakan konvensi baru. Kami membutuhkan cara untuk membuat dua konvensi tumpang tindih selama transisi. Jika kita mengajarkan old go mendapatkan sedikit tentang versi impor semantik, maka kita dapat meningkatkan jumlah tumpang tindih secara signifikan.

Perubahan yang diusulkan: Tetapkan kode "baru" sebagai kode dengan file go.mod di direktori yang sama atau direktori induk. Go get yang lama harus terus mengunduh kode persis seperti biasanya. Saya mengusulkan agar langkah "go build" menyesuaikan penanganan impornya dalam kode "baru". Khususnya, jika impor dalam kode baru mengatakan x/y/v2/z tetapi x/y/v2/z tidak ada dan x/y/go.mod mengatakan "modul x/y/v2", maka go build akan membaca impor sebagai x/y/z sebagai gantinya. Kami akan mendorong pembaruan ini sebagai rilis poin untuk Go 1.9 dan Go 1.10.

Pembaruan : Disalin ke #25069.

Perubahan itu harus memungkinkan paket modul-tidak sadar untuk menggunakan versi yang lebih baru dari paket modul-sadar, apakah paket tersebut memilih pendekatan "cabang utama" atau "subdirektori utama" untuk menyusun repo mereka. Mereka tidak akan lagi dipaksa ke dalam pendekatan subdirektori, tetapi itu masih akan menjadi pilihan yang berfungsi. Dan pengembang yang menggunakan rilis Go yang lebih lama masih dapat membuat kode (setidaknya setelah memperbarui ke rilis titik).

@rsc Saya telah mencoba mencari cara bagaimana kita dapat membuat transisi ke vgo berfungsi juga, saya sampai pada kesimpulan yang sama dengan yang Anda berikan dalam tanggapan Anda dan saran Anda cocok dengan pendekatan terbaik yang saya buat saya sendiri. Saya suka perubahan yang Anda usulkan.

https://github.com/golang/go/issues/24301#issuecomment -377527249, @rsc :

Kemudian kita akan membuat v1.6.0 yang diimplementasikan dengan penerusan ini. v1.6.0 tidak memanggil http.Handle; itu mendelegasikan itu ke v2.0.0. Sekarang expvar v1.6.0 dan expvar/v2 dapat hidup berdampingan, karena kami merencanakannya seperti itu.

Ini terdengar lebih mudah dari itu. Pada kenyataannya, dalam banyak kasus, ini berarti v1.6.0 harus berupa penulisan ulang lengkap v1 dalam bentuk v2 wrapper _(panggilan yang diteruskan ke http.Handle akan mengakibatkan mendaftarkan penangan lain - satu dari v2 - yang pada gilirannya berarti semua yang terkait kode juga harus dari v2 untuk berinteraksi dengan benar dengan hander terdaftar)_.

Hal ini kemungkinan besar akan mengubah detail halus tentang perilaku v1, terutama seiring waktu, seiring berkembangnya v2. Bahkan jika kita dapat mengkompensasi perubahan detail halus ini dan meniru v1 dengan cukup baik di v1.6.x - tetap saja, itu banyak pekerjaan ekstra dan kemungkinan besar membuat dukungan di masa depan untuk cabang v1 (maksud saya penerus v1.5.0 sini) tidak berarti.

@powerman , saya sama sekali tidak mengatakan ini sepele. Dan Anda hanya perlu berkoordinasi sejauh v1 dan v2 memperebutkan beberapa sumber daya bersama seperti pendaftaran http. Tetapi pengembang yang berpartisipasi dalam ekosistem pengemasan ini benar-benar perlu memahami bahwa paket v1 dan v2 mereka harus hidup berdampingan dalam program besar. Banyak paket tidak memerlukan pekerjaan apa pun - yaml dan blackfriday, misalnya, keduanya berada di v2 yang sama sekali berbeda dari v1 tetapi tidak ada status bersama untuk diperebutkan, jadi tidak perlu koordinasi eksplisit - tetapi yang lain akan melakukannya.

@powerman @rsc
Saya sedang mengembangkan paket GUI yang berarti saya bahkan tidak dapat memiliki 2+ instance karena penggunaan utas "utama". Jadi datang dari skenario tunggal terburuk, inilah yang saya putuskan untuk dilakukan.

• Hanya memiliki rilis v0/v1 sehingga tidak mungkin untuk mengimpor 2+ versi

• Memiliki kode publik di folder versi apinya sendiri, misalnya v1/v2 dengan asumsi vgo mengizinkannya atau mungkin api1/api2.

• Paket api publik tersebut kemudian akan bergantung pada paket internal sehingga alih-alih harus menulis ulang pada v2, ini adalah penulisan ulang bergulir saat paket tumbuh dan jauh lebih mudah untuk ditangani.

Di https://github.com/golang/go/issues/24301#issuecomment -377529520 perubahan yang diusulkan mendefinisikan kode "baru" sebagai kode dengan file go.mod di direktori yang sama atau direktori induk. Apakah ini termasuk file go.mod "disintesis" yang dibuat dari membaca dalam dependensi dari Gopkg.toml misalnya?

@zeebo , ya. Jika Anda memiliki file go.mod di pohon Anda, maka asumsinya adalah bahwa kode Anda benar-benar dibuat dengan vgo. Jika tidak, maka rm go.mod (atau setidaknya jangan periksa ke repo Anda di mana orang lain mungkin menemukannya).

@AlexRouSg , rencana Anda untuk paket GUI Anda masuk akal bagi saya.

@rsc hmm.. saya tidak yakin saya mengerti dan maaf jika saya tidak jelas. Apakah paket dengan hanya Gopkg.toml di pohon file dihitung sebagai "baru" untuk definisi?

@rsc

Untuk kode yang dihasilkan secara lebih umum, sistem pembangunan lintas bahasa yang sebenarnya adalah jawabannya, khususnya karena kami tidak ingin setiap pengguna harus menginstal generator yang tepat. Lebih baik bagi penulis untuk menjalankan generator dan memeriksa hasilnya.

Kami berhasil menyelesaikan ini dengan memetakan protobuf ke dalam GOPATH. Ya, kami memilikinya sehingga pengguna biasa tidak memerlukan alat untuk memperbarui, tetapi bagi mereka yang memodifikasi dan membuat ulang protobuf, solusi dalam protobuild bekerja dengan sangat baik.

Jawabannya di sini cukup mengecewakan. Menemukan sistem build baru yang tidak ada hanyalah non-jawaban. Kenyataannya di sini adalah bahwa kami tidak akan membangun kembali sistem pembangunan ini dan kami akan terus menggunakan apa yang berhasil, menghindari adopsi sistem vgo baru.

Apakah vgo hanya menyatakan kebangkrutan bagi mereka yang menyukai dan mengadopsi GOPATH dan mengatasi masalahnya?

@zeebo , tidak, memiliki Gopkg.toml tidak dihitung sebagai baru; di sini "baru" berarti diharapkan menggunakan impor gaya vgo (versi impor semantik).

@stevvooe :

Kami berhasil menyelesaikan ini dengan memetakan protobuf ke dalam GOPATH. ...
Apakah vgo hanya menyatakan kebangkrutan bagi mereka yang menyukai dan mengadopsi GOPATH dan mengatasi masalahnya?

Saya belum melihat protobuild Anda, tetapi secara umum, ya, kami pindah ke model non-GOPATH, dan beberapa trik yang mungkin diaktifkan GOPATH akan tertinggal. Misalnya GOPATH mengaktifkan godep asli untuk mensimulasikan vendor tanpa memiliki dukungan vendor. Itu tidak akan mungkin lagi. Sekilas, sepertinya protobuild didasarkan pada asumsi bahwa ia dapat menjatuhkan file (pb.go) ke dalam paket lain yang tidak Anda miliki. Operasi global semacam itu tidak akan didukung lagi, tidak. Saya benar-benar serius dan tulus ingin memastikan bahwa protobuf didukung dengan baik, terpisah dari vgo. @neild mungkin akan tertarik untuk mendengar saran tetapi mungkin tidak tentang masalah ini.

@stevvooe memberikan komentar @rsc di https://github.com/golang/go/issues/24301#issuecomment -377602765 Saya telah merujuk silang https://github.com/golang/protobuf/issues/526 untuk berjaga-jaga masalah itu akhirnya mencakup sudut vgo . Jika hal-hal tersebut akhirnya ditangani di tempat lain, saya yakin @dsnet dkk akan memberi petunjuk kepada kami.

Catatan: Saya tidak melihat komentar sebelumnya dengan cermat, sepertinya masalah diselesaikan dengan pendekatan yang berbeda. Di bawah ini adalah ide saya.

Hanya sebuah ide.

Bagaimana dengan membuat vgo get mengetahui tag tertentu seperti vgo-v1-lock?
Ketika repositori memiliki tag, itu mungkin mengabaikan tag versi lain, dan disematkan ke tag.

Jadi, ketika repositori menandai v2.1.3 sebagai versi terakhir,
tetapi juga pemiliknya mendorong tag vgo-v1-lock ke komit yang sama yang diberi tag v2.1.3
itu bisa menulis go.mod

require (
    "github.com/owner/repo" vgo-v1-lock
)

Seharusnya tidak diperbarui bahkan jika vgo get -u , hingga pemilik repositori mengubah atau menghapus tag.
Itu bisa membuat repositori besar lebih mudah untuk mempersiapkan pemindahan mereka.

Ketika seorang penulis perpustakaan siap, penulis dapat mengumumkan kepada pengguna
bahwa mereka dapat memperbarui secara manual dengan meletakkan "/ v2" ke jalur impornya.

Bagaimana kami menangani kasus di mana perlu menambal ketergantungan yang dalam (misalnya untuk menerapkan perbaikan CVE yang belum dirilis oleh pembuat asli dalam sebuah tag). Tampaknya strategi vendor dapat menangani ini karena Anda dapat menerapkan tambalan ke rilis penulis asli. Tidak melihat bagaimana vgo dapat menangani ini.

@chirino Anda dapat menggunakan perintah ganti di file go.mod untuk menunjuk ke paket yang ditambal.

@rsc

Sekilas, sepertinya protobuild didasarkan pada asumsi bahwa ia dapat menjatuhkan file (pb.go) ke dalam paket lain yang tidak Anda miliki.

Ini sama sekali bukan apa yang dilakukan proyek. Itu membangun jalur impor dari GOPATH dan dir vendor. File protobuf apa pun di proyek Anda kemudian akan dibuat dengan jalur impor itu. Itu juga melakukan hal-hal seperti impor peta ke paket Go tertentu.

Manfaatnya adalah memungkinkan seseorang untuk menghasilkan protobuf dalam proyek daun yang bergantung pada protobuf lain yang ditentukan dalam dependensi tanpa membuat ulang semuanya. GOPATH secara efektif menjadi jalur impor untuk file protobuf.

Masalah besar dengan proposal ini adalah bahwa kami benar-benar kehilangan kemampuan untuk menyelesaikan file dalam proyek dibandingkan dengan paket Go pada sistem file. Sebagian besar sistem pengemasan memiliki kemampuan untuk melakukan ini, meskipun membuatnya sulit. GOPATH unik karena sangat mudah untuk melakukan ini.

@stevvooe Maaf tapi saya kira saya masih bingung tentang apa yang dilakukan protobuild. Bisakah Anda mengajukan masalah baru "x/vgo: tidak kompatibel dengan protobuild" dan memberikan contoh sederhana dari pohon file yang ada saat ini, apa yang ditambahkan protobuild ke pohon, dan mengapa itu tidak bekerja dengan vgo? Terima kasih.

Bagaimana jika nama modul harus diubah (domain hilang, perubahan kepemilikan, sengketa merek dagang, dll.)?

@jimmyfrasche

Sebagai pengguna:
Kemudian sebagai perbaikan sementara Anda dapat mengedit file go.mod untuk mengganti modul lama dengan yang baru sambil mempertahankan jalur impor yang sama. https://research.swtch.com/vgo-tour

Tetapi dalam jangka panjang, Anda ingin mengubah semua jalur impor dan mengedit file go.mod untuk menggunakan modul baru. Pada dasarnya hal yang sama yang harus Anda lakukan dengan atau tanpa vgo.

Sebagai pengelola paket:
Cukup perbarui file go.mod untuk mengubah jalur impor modul dan beri tahu pengguna Anda tentang perubahan tersebut.

@jimmyfrasche ,

Bagaimana jika nama modul harus diubah (domain hilang, perubahan kepemilikan, sengketa merek dagang, dll.)?

Ini adalah masalah nyata yang sudah ada sebelumnya yang tidak coba ditangani oleh proposal vgo secara langsung, tetapi jelas kita harus mengatasinya pada akhirnya. Jawaban atas hilangnya kode adalah memiliki proxy caching (mirror) bersama dengan alasan untuk mempercayainya; itu pekerjaan masa depan. Jawaban untuk pemindahan kode adalah dengan menambahkan konsep eksplisit dari pengalihan modul atau paket, seperti halnya alias tipe adalah pengalihan tipe; itu juga pekerjaan masa depan.

Jawaban untuk kode yang menghilang adalah memiliki proxy caching (mirror)

IMO yang benar-benar untuk perusahaan. Sebagian besar perusahaan kecil dan lainnya akan baik-baik saja dengan vendor dan melakukan semua dependensi ke dalam repo yang sama

Mengajukan #24916 untuk kompatibilitas yang saya sebutkan di komentar di atas.
Juga mengajukan #24915 mengusulkan untuk kembali menggunakan git dll secara langsung alih-alih bersikeras pada akses HTTPS. Tampaknya jelas bahwa penyiapan hosting kode belum siap untuk API saja.

proposal kecil untuk membuat konsistensi dalam file mod dengan perintah vgo get yang direncanakan

Dalam dokumen "vgo-tour", perintah vgo get ditampilkan sebagai:

vgo get rsc.io/[email protected]

Bagaimana dengan mirroring format ini di file mod? Sebagai contoh:

module "github.com/you/hello"
require (
    "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54
    "rsc.io/quote" v1.5.2
)

bisa saja:

module "github.com/you/hello"
require (
    "golang.org/x/[email protected]"
    "rsc.io/[email protected]"
)

• meningkatkan konsistensi dengan baris perintah
• pengenal tunggal mendefinisikan item sepenuhnya
• struktur yang lebih baik untuk mendukung operasi yang ditentukan dalam file mod yang memerlukan beberapa pengidentifikasi paket berversi

Mencari kejelasan lebih lanjut tentang bagaimana proposal ini menangani distribusi paket "biner saja".

versi/distribusi perpustakaan biner tampaknya tidak muncul di dokumen deskripsi apa pun di sekitar vgo. apakah ada kebutuhan untuk melihat ini lebih hati-hati?

Cara kerjanya hari ini, jika saya dapat menggunakan alat git biasa, go get akan bekerja dengan baik. Tidak masalah apakah itu repositori Github pribadi atau server Git saya sendiri. Saya sangat menyukainya.

Menurut apa yang saya pahami, tidak mungkin untuk terus bekerja seperti itu. Benarkah? Jika ya, apakah mungkin untuk mempertahankan opsi menggunakan biner git yang diinstal secara lokal untuk checkout kode? (acara itu menggunakan bendera CLI eksplisit)

@korya Silakan lihat masalah yang baru saja diajukan https://github.com/golang/go/issues/24915

@sdwarwick , kembali https://github.com/golang/go/issues/24301#issuecomment -382791513 (sintaks go.mod), lihat #24119.

re https://github.com/golang/go/issues/24301#issuecomment -382793364 , mungkin saya tidak mengerti apa yang Anda maksud, tetapi go get tidak pernah mendukung paket hanya biner, dan kami tidak berencana untuk menambahkan dukungan. Terlalu sulit untuk menghitung semua kemungkinan binari berbeda yang mungkin dibutuhkan seseorang. Lebih baik meminta sumber dan dapat mengkompilasi ulang ketika dependensi atau kompiler berubah.

@rsc Saya percaya https://github.com/golang/go/issues/24301#issuecomment -382793364 mengacu pada
https://golang.org/pkg/go/build/#hdr -Binary_Only_Packages

@AlexRouSg Ya. Itu tidak didukung oleh "go get" (tetapi "go build" mendukungnya sebagai tipe build), yang dimaksud @rsc . Distribusi jenis paket tersebut harus dilakukan secara eksternal ke alat "go get", dan dengan demikian kemungkinan sama untuk proposal baru ini.

Saya berharap dukungan saat ini untuk paket biner saja akan terus bekerja seburuk yang pernah bekerja. Saya tidak akan berusaha keras untuk menghapusnya.

Saya memperbarui ringkasan diskusi lagi. Saya juga mengajukan #25069 untuk saran saya sebelumnya tentang kesadaran modul minimal di cmd/go lama.

@kybin , kembali https://github.com/golang/go/issues/24301#issuecomment -377662150 dan tag vgo-v1-lock , saya melihat daya tariknya tetapi menambahkan kasus khusus untuk itu berarti menambahkan lebih banyak kasus khusus di seluruh dukungan modul lainnya. Saya tidak berpikir manfaat sebanding dengan biaya dalam kasus ini. Orang sudah dapat menggunakan versi semu untuk mendapatkan efek serupa. Saya juga khawatir bahwa tag akan berpindah dan/atau orang tidak akan menghormati kompatibilitas mundur dengan benar (misalnya memindahkan vgo1-v1-lock dari v2.3.4 ke v3.0.0 hanya untuk menghindari versi impor semantik). Jadi pada keseimbangan saya pikir kita mungkin tidak harus melakukan ini.

Saya pikir sudah waktunya untuk menandai proposal ini diterima.

Tidak pernah ada ketegangan tentang apakah itu akan diterima dalam beberapa bentuk. Alih-alih, tujuan diskusi di sini adalah untuk menemukan bentuk yang tepat, untuk mengidentifikasi apa yang harus kita sesuaikan. Seperti yang saya tulis di posting blog :

Saya tahu ada masalah yang tidak dapat dilihat oleh tim Go dan saya, karena pengembang Go menggunakan Go dengan banyak cara cerdas yang tidak kami ketahui. Tujuan dari proses umpan balik proposal adalah agar kita semua bekerja sama untuk mengidentifikasi dan mengatasi masalah dalam proposal saat ini, untuk memastikan bahwa implementasi akhir yang dikirimkan dalam rilis Go mendatang berfungsi dengan baik untuk sebanyak mungkin pengembang. Tolong tunjukkan masalah pada masalah diskusi proposal. Saya akan terus memperbarui ringkasan diskusi dan FAQ saat umpan balik tiba.

Ringkasan diskusi dan FAQ adalah yang terbaru untuk saat ini. Diskusi di sini dan di luar masalah mendorong perubahan penting berikut:

• kesadaran modul minimal di cmd/go lama, #25069.
• memulihkan dukungan vendor minimal, #25073.
• memulihkan dukungan untuk akses Git langsung, #24915.
• hilangkan tanda kutip di go.mod, #24641.
• dukungan yang lebih baik untuk gopkg.in, #24099, lainnya.
• dukungan untuk penamaan yang dilakukan oleh pengidentifikasi cabang, #24045.

Itu juga mendorong diskusi tentang kemungkinan mengubah nama file dan sintaks go.mod, tetapi satu-satunya perubahan yang dihasilkan adalah menghilangkan tanda kutip.

Diskusi telah mereda, dan juga menjadi cukup lama sehingga cukup menyakitkan untuk dimuat di GitHub (ternyata 100 komentar terlalu banyak!). Dengan menandai proposal yang diterima, kami dapat fokus menggunakan vgo dan menyiapkannya untuk dimasukkan dalam Go 1.11 sebagai "pratinjau", dan kami dapat beralih ke masalah yang dapat dimuat GitHub lebih cepat.

Tentu saja masih ada lebih banyak bug yang harus ditemukan dan diperbaiki, dan lebih banyak penyesuaian desain yang harus dilakukan. Diskusi tentang detail tersebut dapat dilakukan pada isu-isu baru yang spesifik untuk detail tersebut. Harap gunakan awalan "x/vgo:" dan pencapaian vgo .

Terimakasih semuanya.

@rsc Apa cara untuk mencoba vgo sekarang? Haruskah kita mengambil dan membangun github.com/golang/vgo atau github.com/golang/go?

@ngrilly tetap menggunakan go get -u golang.org/x/vgo .

@rsc terima kasih atas kerja keras dan waktu yang Anda berikan untuk proposal ini. Saya sangat berharap kita akhirnya sampai pada titik di mana ada cerita bagus seputar manajemen ketergantungan Go.

Saya pikir sudah waktunya untuk menandai proposal ini diterima.

Saya rasa tidak pantas bagi seseorang yang mengajukan proposal untuk menyatakan kapan siap untuk diterima. Saya pikir mereka yang mengajukan proposal, terutama yang sebesar ini dan berpendirian, seharusnya tidak memiliki suara untuk diterima. Pengajuan proposal mereka mengomunikasikan bias mereka. Di sisi lain, saya pikir penulis pasti harus memiliki suara dalam menolak proposal jika mereka berubah pikiran setelah mengajukannya.

Saat ini rasanya seperti ada ketidaksepakatan mendalam seputar keputusan teknis dalam vgo , yang saya khawatirkan akan memecah komunitas _dan_ ekosistem. Dengan mengingat hal itu, saya merasa kita harus memberikan sedikit lebih banyak waktu untuk menyelesaikan proposal yang bersaing dan mendapat sorotan. Setelah itu terjadi, kita perlu memiliki pihak _netral_ yang terdiri dari perwakilan dari beberapa perusahaan, dan komunitas, untuk memfasilitasi diskusi dan keputusan akhir.

Saya semakin khawatir bahwa sebagian besar kepemimpinan Go telah menjadi terlalu terisolasi dari komunitas di belakang Go (termasuk perusahaan lain yang menggunakannya), dan akibatnya bahasa dan ekosistem mulai rusak. Inilah mengapa saya pikir kita perlu memiliki grup netral, dengan perwakilan yang mencerminkan pengguna bahasa pemrograman Go, membantu meratifikasi proposal seperti ini.

Pada akhirnya, bekerja sebagai insinyur perangkat lunak di dalam Google menghasilkan perspektif yang berbeda dibandingkan dengan sebagian besar industri. Memiliki banyak pengembang inti yang berada di dalam Google tidak berkontribusi pada keragaman yang kami butuhkan saat mendorong Maju.

@theckman Garis pemikiran Anda tampaknya:

1. Keputusan tentang Go dibuat oleh tim kecil yang sebagian besar terdiri dari insinyur Google.
2. Insinyur Google terisolasi dari komunitas lainnya, karena kebutuhan Google sangat spesifik.
3. Ini mengarah pada keputusan yang mendukung perspektif Google dan tidak disesuaikan dengan pengguna Go lainnya.
4. Ini bisa melukai dan memecah komunitas Go.
5. Untuk mengatasi masalah ini, Go harus mengadopsi proses keputusan formal di mana keputusan dibuat secara kolegial oleh sebuah kelompok yang mencerminkan keragaman komunitas Go (sesuatu yang "demokratis").

Secara teori, saya cenderung menyukai sesuatu yang "demokratis", tetapi dalam praktiknya:

• Saya rasa keputusan yang dibuat oleh tim Go tidak bias terhadap kebutuhan Google, dengan mengorbankan pengguna Go "kecil". Sebagai pengembang di toko yang sangat kecil (kebalikan dari Google), saya merasa Go sangat cocok dengan kebutuhan kami, dan saya tahu tim kecil lain di sekitar saya dengan senang hati menggunakan Go. Secara pribadi, satu-satunya keluhan yang saya miliki dengan bahasa Go telah diakui oleh tim Go (manajemen ketergantungan, kurangnya obat generik, penanganan kesalahan verbose) dan saya yakin mereka sedang mengerjakannya. Bisakah Anda memberikan contoh keputusan yang dibuat oleh tim Go yang akan berbeda dan lebih baik melayani "seluruh komunitas" jika kita memiliki proses "demokratis"?

• Saya tidak yakin bahwa mengadopsi proses keputusan "demokratis" akan secara otomatis menyelesaikan masalah yang Anda sebutkan dan menghilangkan risiko "memecahkan" komunitas. Ini bisa menjadi peningkatan dari model BDFL , tetapi itu bukan jaminan stabilitas itu sendiri. Sejarah open source, dan sejarah manusia pada umumnya, memberikan banyak contoh masyarakat demokratis yang telah dirusak oleh perbedaan pendapat dan konflik.

@theckman , sementara @ngrilly mencoba bersikap sopan, saya akan tegas: jika Anda melihat masalah teknis mengapa proposal vgo tidak siap untuk diterima - beri tahu kami secepatnya dan di sini! Jika Anda yakin beberapa masalah yang diketahui tidak ditangani secara memadai - beri tahu kami. Jika tidak ada kasus seperti itu - apa bedanya siapa yang akan mengatakan "saatnya menerima proposal"? Kami punya waktu dua bulan untuk membahasnya, jika Anda yakin ada alasan teknis mengapa itu tidak cukup - beri tahu kami.

Sepertinya Anda ingin menambahkan lebih banyak politik di sini tanpa alasan, yang hanya akan memperlambat segalanya, dan itu jika kita cukup beruntung dan tidak ada kerugian lain. Dan bahkan jika Anda yakin ada alasan untuk ini - ini bukan tempat yang tepat untuk membahas ini - silakan mulai diskusi ini di maillist.

Maaf untuk satu lagi komentar di luar topik, semuanya!

@powerman Maaf lumpuh dan kutip komentar saya sebelumnya:

Saat ini rasanya seperti ada ketidaksepakatan mendalam seputar keputusan teknis dalam vgo, yang saya khawatirkan akan memecah ekosistem dan komunitas. Dengan mengingat hal itu, saya merasa kita harus memberikan sedikit lebih banyak waktu untuk menyelesaikan proposal yang bersaing dan mendapat sorotan.

Saya tahu ada proposal alternatif yang akan datang, dan permintaan saya adalah untuk tidak menerima ini sampai mereka punya waktu. Kami tidak memiliki manajemen ketergantungan untuk sementara waktu sekarang, jadi saya pikir itu tidak masuk akal untuk meminta kunjungan singkat sambil mengizinkan sentuhan akhir pada proposal lain.

Saya tidak yakin mudah untuk mengartikulasikannya dengan baik dalam masalah ini, hanya karena formatnya agak terbatas. Bahkan kemudian saya akan ragu-ragu, karena pada dasarnya saya akan menduplikasi bagian dari proposal WIP. Saya tidak ingin memecah-mecah ide atau mencuri guntur dari para penulis.

Namun, mengetahui proposal tersebut sedang berlangsung dan siapa yang mengerjakannya, rasanya deklarasi kesiapan ini merupakan upaya aktif untuk meredam pendapat yang bersaing itu. Saya merasa terdorong untuk menyampaikan kekhawatiran ini karena pola yang saya amati selama bertahun-tahun sebagai Gopher. Saya benar-benar ingin bahasa, ekosistem, dan komunitas berhasil, dan ini diangkat semata-mata dengan tujuan itu dalam pikiran.

Sunting: Untuk memperjelas, dengan kunjungan singkat saya tidak bermaksud dua bulan atau semacamnya. Maksudku beberapa minggu.

@ngrilly Maaf, saya tidak bermaksud mengabaikan komentar Anda. Saya berencana untuk membahasnya dengan yang sebelumnya, tetapi akhirnya menjadi lebih bertele-tele daripada yang saya inginkan.

Saya pikir ada dua masalah. Sementara saya merasa ada sesuatu yang harus didiskusikan di forum yang berbeda tentang bagaimana keputusan ini dibuat, itulah sebabnya saya menambahkan beberapa konteks di sekitar itu, saya benar-benar ingin fokus untuk menghentikan sementara penerimaan proposal ini sampai proposal lainnya selesai. memiliki kesempatan untuk menjadi publik.

Saya tahu ada proposal alternatif yang akan datang, dan permintaan saya adalah untuk tidak menerima ini sampai mereka punya waktu. ... [K]mengetahui proposal tersebut sedang dalam proses dan siapa yang mengerjakannya, rasanya pernyataan kesiapan ini adalah upaya aktif untuk meredam pendapat yang bersaing itu.

Saya jamin itu tidak. Saya sudah cukup jelas tentang timeline di sini. Posting pertama saya dari pertengahan Februari mengatakan tujuannya adalah untuk mengintegrasikan proposal vgo ke dalam Go 1.11; pendekatan pembekuan pembangunan. Saya tidak tahu apa-apa tentang proposal lain yang sedang berjalan atau siapa yang sedang mengerjakannya. Itu berita bagi saya. Jika orang ingin terlibat dengan proposal ini atau membuat proposal balasan, proposal ini telah dibuka selama satu setengah bulan, jadi agak terlambat.

Untuk lebih jelasnya, saya tidak menandai proposal tersebut diterima, terlepas dari apa yang dilaporkan oleh Golang Weekly dan mungkin yang lain. Saya hanya mengatakan bahwa saya pikir sudah waktunya untuk melakukannya. Artinya, saya tidak menerapkan label Proposal-Diterima, justru karena saya ingin memeriksa apakah ada konsensus umum untuk melakukannya terlebih dahulu. Dan konsensus umum tampaknya mendukung penerimaan, setidaknya dilihat dari keseluruhan diskusi di sini serta penghitung emoji di https://github.com/golang/go/issues/24301#issuecomment -384349642.

Saya tahu ada proposal alternatif yang akan datang

@theckman , jika Anda tahu tentang sesuatu seperti ini, Anda mungkin satu-satunya yang mengetahuinya. Sampai saat ini, saya belum melihat ada orang yang mengangkat masalah ini sampai sekarang. Saya pikir pernyataan Russ tentang keinginan untuk mencoba ini untuk Go 1.11 sangat jelas dari awal, jadi jika ada yang mengerjakan proposal alternatif, mereka memiliki waktu sekitar 2 bulan untuk mengajukannya, bahkan sebagai pendahuluan.

Saya juga berpikir bahwa kita dapat menerima kenyataan bahwa Tim Go memiliki rekam jejak yang baik untuk tidak mengambil keputusan secara tiba-tiba, dan jika kita melihat bagaimana mereka menarik Alias ​​​​pada saat-saat terakhir dari Go 1.8 karena itu tidak tepat. hal yang harus dilakukan pada saat itu, maka kita mungkin harus memberi mereka izin untuk setidaknya mengizinkan mereka membangun eksperimen/solusi mereka sendiri.

Pada akhirnya, proposal membawa lebih dari sekadar algoritme tentang cara memilih versi ketergantungan yang digunakan. Jika ada yang menemukan cara untuk meningkatkannya, maka ada dua opsi: kirimkan melalui proses CL biasa ATAU buat alat mereka sendiri dan biarkan komunitas menggunakannya, jika mereka memilih untuk melakukannya. Tim Go masih dapat menyediakan alat versi mereka sendiri, jadi saya tidak melihat ini memiliki masalah tertutup.

Namun, perlu diingat bahwa sebagian besar tindakan memecah belah yang selama ini dilakukan oleh komunitas, bukan Go Team. Mari beri kesempatan kepada Tim Go untuk membuat alat, lalu mengevaluasinya, saat memungkinkan untuk melakukannya, lalu mengajukan argumen tentang cara meningkatkannya dan bergerak maju daripada menulis tentang seberapa buruknya.

Harap pertimbangkan ini sebagai bagian dari jenis laporan pengalaman yang berbeda: laporan di mana saya _sangat_ menentang proposal Alias ​​​​untuk kemudian memahami dan sekarang melihat proposal dalam tindakan.

Sunting: pesan asli memiliki penghilangan yang sangat disayangkan record of *not* making decisions on a whim seharusnya teks, sayangnya bagian "tidak" hilang. Saya minta maaf untuk itu.

saya memiliki catatan rinci tentang masalah mendasar dengan proposal tersebut. saya telah mencoba untuk menyelesaikan tulisan ini sehingga saya dapat memperkenalkan semuanya sekaligus - ini adalah domain yang kompleks dan halus dan dengan demikian, masalah ini harus ditangani secara totalitas - tetapi kehidupan dan pekerjaan telah membuatnya sulit.

Meskipun saya telah menyinggung artikel ini di Slack, dan juga membahas bagian-bagiannya secara langsung dengan @rsc , saya memilih untuk tidak menyebutkannya di sini sampai sekarang. Bagi saya, mengiklankan artikel ini sebelum saya siap untuk merilisnya sepenuhnya tidak akan terlalu membangun. Tapi, seperti yang telah dicatat, ini sudah dua bulan, jadi saya akan membuat dorongan besar untuk memulai seri ini minggu depan.

(edit: ini adalah "alternatif" yang dirujuk oleh @theckman )

@sdboyer Anda menyebutkan bahwa Anda memiliki banyak masalah. Bisakah Anda setidaknya mempublikasikan daftar mereka sekarang?
Saya bekerja dengan beberapa sistem yang membawa ketergantungan neraka ke tingkat lain (chef, go, npm, composer) dan dari pengalaman proposal ini adalah solusi untuk semuanya dalam hal go.

@theckman , dapatkah Anda mengonfirmasi bahwa Anda hanya merujuk pada umpan balik @sdboyer ? Itu bukan rahasia. Sam menyebutkannya secara harfiah pada hari pertama vgo dirilis ("saya menulis dokumen yang lebih rinci tentang kekhawatiran saya" - https://sdboyer.io/blog/vgo-and-dep/). Tapi itu umpan balik, bukan proposal, dan Anda berkali-kali merujuk ke "proposal lain", jamak. Apakah ada lebih banyak yang Anda ketahui?

Apa implikasi vgo bagi pengguna go/types API? Apa status dukungan go/types saat ini?

Saya menerima PR mdempsky/gocode#26 untuk menambahkan implementasi vgo-aware go/types.Importer, tetapi tidak jelas bagi saya apakah/mengapa ini perlu.

Dengan asumsi itu perlu, dapatkah kita menambahkan vgo-aware go/types.Importer kanonik di tempat lain (misalnya, repo x/vgo atau x/tools) sehingga alat berbasis go/types tidak perlu masing-masing mengimplementasikan kembali dukungan ini ?

Saya belum benar-benar mengikuti detail vgo, jadi mungkin ini hanya "tidak berdampak", tetapi saya tidak melihat penyebutan go/tipe di atas. Pencarian Google untuk "vgo go/types golang" juga tidak informatif.

Terima kasih.

@mdempsky , rencananya adalah memiliki pemuat paket vgo-aware (dan dalam hal ini membangun cache-aware), mungkin golang.org/x/tools/go/packages, tetapi belum ada. Orang harus menunggu paket itu alih-alih menulis kode yang perlu dibuang. Jangan gabungkan PR. Saya mengomentarinya.

@mdempsky akan membalas di https://github.com/mdempsky/gocode/pull/26 tapi saya akan membalas di sini untuk saat ini.

https://github.com/mdempsky/gocode/pull/26 sepenuhnya dibuang; hanya bukti konsep yang menggunakan CL yang sekarang ditinggalkan terhadap vgo .

Saya baru saja melihat balasan @rsc jadi saya hanya akan menunjukkan bahwa ada juga diskusi yang sedang berlangsung di https://github.com/golang/go/issues/14120#issuecomment -383994980.

Ringkasan: setelah beberapa tahun pengalaman dengan versi, upaya terbaik terakhir adalah algoritma yang sangat kompleks, pemecah sat. Tetapi jika Anda membuat beberapa modifikasi sederhana pada data input, masalah keputusan NP-complete menjadi sesuatu yang tidak hanya dapat dikelola, tetapi juga sangat cepat.

Sebagai pengguna tim kecil Go dengan banyak pengalaman menggunakan NPM, saya sangat menyukai proposal vgo. FWIW, saya menantikan vgo diimplementasikan di go yang tepat dan semakin cepat itu menjadi lebih baik untuk tim saya dan saya.

Bukannya saya orang yang istimewa, hanya karena saya melihat diskusi tentang masalah tim kecil, saya pikir saya akan ikut campur.

Berikut adalah ulasan saya.

Di permukaan, bagian _Proposal_ dari revisi terakhir dari dokumen proposal tampak baik-baik saja, jika tidak terlalu spesifik (misalnya tidak jelas sejauh mana Subversion mungkin didukung). Satu pengecualian adalah bahwa "Larang penggunaan direktori vendor, kecuali dalam satu penggunaan terbatas" tampaknya mengatakan bahwa direktori vendor tidak akan didukung dalam paket non-modul sama sekali; Apakah begitu?

Di sisi lain, proposal menyiratkan keputusan desain dan implementasi tertentu yang merusak berbagai manfaat dari go get saat ini. Kerugian mungkin dapat diterima, beberapa mungkin dihindari, tetapi jika vgo get akan menggantikan go get , kerugian tersebut harus ditangani sebagai pertimbangan desain dan didiskusikan, karena jika tidak, kita mungkin akan mendapatkan alat yang bukan pengganti yang memadai, dan vgo tidak akan digabungkan menjadi go atau go get harus dibangkitkan sebagai alat pihak ketiga.

Bagian _Implementasi_ mengatakan: “Dalam rilis selanjutnya (katakanlah, Go 1.13), kami akan mengakhiri dukungan untuk go get non-modul. Dukungan untuk bekerja di GOPATH akan berlanjut tanpa batas.” Ini merepotkan. Pertama, ada banyak proyek bagus yang belum diperbarui selama bertahun-tahun. Mereka masih berfungsi berkat janji kompatibilitas Go 1, tetapi banyak yang tidak akan menambahkan file go.mod . Kedua, ini memaksa pengembang proyek tanpa ketergantungan atau mereka yang tidak peduli dengan versi untuk menambahkan file modul atau menghindari ekosistem go get yang baru. Anda mungkin dibenarkan untuk menginginkan ini, tetapi tolong jelaskan mengapa. (Bagi saya tampaknya tidak perlu rumit; Saya lebih suka menggunakan garpu go get lama. Saya setuju bahwa manajer paket untuk bahasa lain bahkan lebih rumit, dan saya yakin vgo lebih baik dari mereka, tetapi tidak menangani kasus penggunaan saya lebih baik daripada go get saat ini, dengan bantuan sesekali dari govendor ).

Perhatian utama saya tentang vgo vs go adalah dengan alur kerja yang mereka dukung. Saya telah mengungkapkannya di posting vgo-intro. Ini mungkin secara luas termasuk dalam bagian _Kompatibilitas_ proposal, atau mungkin di luar cakupannya, tetapi ini sesuai dengan pertanyaan dan masalah lain yang diangkat di sini.

Dalam beberapa rilis selanjutnya, kami akan menghapus dukungan untuk go get yang lama dan tidak berversi.

Sementara aspek lain dari proposal terdengar baik-baik saja, yang satu ini sangat disayangkan. (Sedemikian rupa sehingga jika saya harus memilih antara memasukkan versi ke dalam go toolchain dan terus bekerja dengan alat kontrol versi, saya akan memilih yang terakhir.) Keuntungan dari vgo adalah memfasilitasi pembuatan yang dapat direproduksi dan menunda kerusakan proyek Anda karena pembaruan yang tidak kompatibel hingga Anda sebagai pembuat proyek (dengan file go.mod) ingin menghadapinya; tetapi keuntungan go get adalah ia membawa manfaat monorepo ke dunia multi-repositori: karena klon dependensi yang lengkap, Anda dapat bekerja dengannya semudah dengan proyek Anda sendiri (periksa riwayat, edit, perubahan diff; pergi ke definisi apa pun dan menyalahkannya), itu memfasilitasi kolaborasi (Anda cukup mendorong dan mengusulkan perubahan Anda) dan umumnya memaksakan pandangan bahwa setiap saat hanya ada satu keadaan dunia saat ini — ujung dari setiap proyek — dan semuanya lain adalah sejarah. Saya pikir pendekatan unik ini (di luar monorepos sebenarnya) adalah anugerah khas ekosistem Go yang lebih baik daripada buruk, dan tidak boleh ditinggalkan.

Konsekuensi negatif yang lebih halus dari proposal adalah membuat pembuatan versi tidak dapat disembuhkan dan diwariskan: setelah sebuah proyek menandai sebuah versi, ia tidak dapat mengharapkan perubahan di masa mendatang untuk menjangkau pengguna tanpa menandai versi baru. Bahkan jika penulis asli tetap bertekad untuk terus menandai, penulis fork sekarang dipaksa untuk menandai mereka juga (yang sangat canggung jika proyek sumber masih aktif), atau menghapus tag lama.

Secara keseluruhan, saya ingin menekankan bahwa pendekatan Go saat ini untuk manajemen ketergantungan secara keseluruhan lebih unggul daripada pembuatan versi. Ini selaras lebih baik dengan open source modern, dinamis dan kolaboratif yang mengharapkan bahwa semua komit terlihat, dan hanya menerbitkan sumber rilis (atau "mengintegrasikan perubahan internal" dalam komit nondeskriptif besar) tidak cukup (karena sangat mengurangi visibilitas, kolaborasi dan dinamis). Dapat dilihat baik di monorepos maupun di ekosistem Go saat ini bahwa sebagian besar proyek tidak memerlukan versi. Tentu saja pendekatan ini bukan yang utama, memiliki kelemahan, dan penting untuk mendukung proyek berversi juga, tetapi ini tidak boleh dilakukan dengan merugikan tanpa versi.

Untuk meringkas, go get saat ini (dengan alat bantu, misalnya godef ) mendukung alur kerja yang menampilkan:

• kode sumber dependensi yang dapat diedit
• kode sumber dependensi di bawah VCS mereka
• revisi terbaru dari dependensi

Saya kira saya dapat berasumsi bahwa kode sumber dependensi akan tetap dapat diedit, yaitu godef akan menautkan ke _file_ yang _tidak dilindungi penulisannya_ dan _digunakan selama pembuatan_. Namun, vgo akan mengingkari dua poin lainnya. Sehubungan dengan poin kedua, #24915 telah memperpanjang dukungan untuk alat VCS, tetapi masih menyatakan tujuan untuk menghentikannya; dan alur kerja tidak hanya mengharuskan dependensi diperiksa dari VCS, tetapi juga bahwa checkout berguna untuk pengembang (misalnya bukan git checkout yang dangkal, bukan git checkout dengan .git dihapus) dan digunakan selama build , tetapi vgo mungkin tidak memenuhi persyaratan ini. Sehubungan dengan poin ketiga, saya telah membenarkan nilainya dalam komentar vgo-intro, tetapi vgo tampaknya mengabaikannya sama sekali.

Alat pembuatan versi Go tidak harus menghentikan dukungan untuk alur kerja saat ini, dan tidak boleh menghapusnya untuk mempertahankan manfaat unik dari bekerja di ekosistem Go dan menjadi pengganti yang memadai untuk go get . Desain vgo membuat ini menantang, tetapi tidak jelas tidak mungkin. Bagian _Proposal_ dari proposal, di sisi lain, tampaknya hampir kompatibel dengan alur kerja saat ini. Satu-satunya tantangan yang diperkenalkan untuk mendukung poin ketiga (memeriksa revisi terbaru) — dan ini adalah salah satu yang besar — ​​adalah menyulitkan untuk memutuskan modul v2.0.0 apakah modul tersebut dapat diperiksa di master , atau apakah mereka harus diperiksa seperti yang ditentukan karena master ada di versi utama lainnya. Ini bukan tantangan untuk go get saat ini dengan gopkg.in karena semuanya diperiksa di master secara default, dan barang-barang di gopkg.in diperiksa di tag atau cabang yang cocok; tetapi vgo mengaburkan perbedaan ini dan menyebarkan model gopkg.in ke semua paket. (Selain itu, berhenti mencocokkan cabang.) Akibatnya menjadi tidak mungkin untuk memastikan dan perlu menebak bagaimana mendapatkan revisi terbaru dari versi utama yang ditentukan.

Saya mungkin melewatkannya, tetapi bagaimana vgo akan bekerja dalam skenario ini?

• Saya bekerja pada layanan A dan layanan B keduanya bergantung pada lib X (yang juga saya kerjakan)
• Saya membutuhkan perubahan besar dalam lib X

Dengan cara melakukan saat ini, saya hanya melakukan perubahan saya, mengkompilasi layanan A dan layanan B, mereka mengambil apa pun yang ada di $GOPATH saya untuk lib X, saya memperbaiki hal-hal, lalu saya Push lib X dengan benjolan semver utama, lalu Dorong kedua layanan A dan B memberi tahu mereka untuk menggunakan mayor baru lib X di Gopkg.toml mereka.

Sekarang ketika vgo mengambil alih, go build pada layanan saya akan mencoba menemukan versi baru lib X yang tidak ada dari github, dan saya dapat memperkirakan semua jenis masalah.

Jadi, apakah saya melewatkan sesuatu yang jelas?

Anda dapat menggunakan direktif replace untuk hal semacam ini.

Pada Senin, 30 April 2018, 12:15 Antoine [email protected] menulis:

Saya mungkin melewatkannya, tetapi bagaimana vgo akan bekerja dalam skenario ini?

• Saya bekerja pada layanan A dan layanan B keduanya tergantung pada lib X (bahwa saya
  juga bekerja)
• Saya membutuhkan perubahan besar dalam lib X

Dengan cara melakukan saat ini, saya hanya melakukan perubahan, mengkompilasi layanan A dan
service B, mereka mengambil apa pun yang ada di $GOPATH saya untuk lib X, saya memperbaikinya,
lalu saya Dorong lib X dengan benjolan semver besar, lalu Dorong kedua layanan A dan B
memberitahu mereka untuk menggunakan mayor baru lib X di Gopkg.toml mereka.

Sekarang ketika vgo mengambil alih, pergi membangun layanan saya akan mencoba untuk menemukan non
versi baru lib X yang ada dari github, dan saya dapat memperkirakan semua jenis
masalah.

Jadi, apakah saya melewatkan sesuatu yang jelas?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/24301#issuecomment-385499702 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAuFsfnD8_kbUj8fSXvGgeN77ki6KYM6ks5tt2LLgaJpZM4Sg3bp
.

@kardianos ya, tapi itu masih berarti saya harus mendorong perubahan lib saya untuk mencoba?

EDIT: sepertinya Anda dapat menggunakan jalur untuk mengganti ( https://github.com/golang/go/issues/24110 ), yang bagus. Tetapi saya juga dapat memprediksi bahwa ini akan berakhir berkali-kali.

Adakah rencana untuk dapat membuat file tambahan, seperti go.mod.replace atau sesuatu seperti itu, sehingga kami dapat menentukan penggantian di lingkungan dev dan gitignore?

@primalmotion Untuk mencegah komit buruk, Anda mungkin harus menggunakan git hook.

Tapi saya kira jawaban yang tepat adalah jangan lakukan ini (ganti ke jalur lokal) terlalu sering. Jika perpustakaan Anda sangat erat digabungkan maka seharusnya tidak hidup dalam repo terpisah (dan dengan demikian berpura-pura digabungkan secara longgar). Secara umum, Anda harus dapat memperbaiki, menguji, dan merilis lib itu tanpa memperhitungkan implementasi layanan ini saat ini. Terutama dengan vgo, yang menjamin kedua layanan akan terus menggunakan versi lib yang lebih lama (yang mereka gunakan sebelumnya) hingga Anda memperbaruinya secara manual ke versi lib yang lebih baru. Jika Anda sesekali akan melakukan ganti ke jalur lokal setahun sekali - ini bukan masalah besar, CI akan membantu Anda memperhatikan dan memperbaikinya dalam beberapa menit.

@primalmotion dengan go.mod.replace tidak berversi Anda dapat melakukan proyek yang tidak akan dapat direproduksi. Alih-alih, dengan replace di go.mod Anda yakin bahwa Anda melakukan persis apa yang saat ini Anda gunakan dan uji.
Ini bisa menjadi kesalahan untuk melakukan dengan penggantian tetapi Anda akan menyadarinya dan memperbaikinya.
Atau bisa juga sukarela, saya melakukannya dengan submodul, tidak masalah ketika Anda mengerjakan proyek dan lib bersama-sama dan dapat direproduksi jika Anda melakukan submodule. Saya sering melakukannya dengan Python dan melewatkannya dengan Go. Dengan vgo saya senang bisa bekerja seperti itu lagi. _(berharap menjadi jelas dengan bahasa Inggris saya yang buruk, maaf)._

Nah, masalahnya adalah kita tidak peduli dengan build yang dapat direproduksi sampai kita memutuskan bahwa kita peduli (yaitu saat kita menyiapkan rilis). Kami memiliki lingkungan dev yang sangat gesit di mana memperbarui lib hanya dengan checkout, membangun kembali, menjalankan tes. Kami tidak melakukan Gopkg.lock di cabang utama layanan kami, hanya toml dengan versi tetap untuk lib eksternal, dan kendala utama pada kami. Setelah kami membuat cabang rilis, lalu kami melakukan Gopkg.lock dan baru kemudian kami memiliki build yang dapat direproduksi (ini dilakukan oleh ci kami).

Vgo pada dasarnya merusak semua alur kerja yang telah kami bangun selama bertahun-tahun. Sekarang hanya untuk mencoba sesuatu yang bodoh seperti sedikit debug cetak di lib (karena kita semua melakukan ini, jangan berbohong :)), atau sedikit optimasi, kita harus memeriksa lusinan layanan, tambahkan replace di mana-mana, uji, lalu kembali dan hapus semuanya.

Apa yang bisa membuat vgo bekerja untuk kita:

• sistem override seperti yang saya sebutkan
• cara untuk tidak menggunakannya sama sekali dan kembali ke GOPATH lama yang bagus untuk pengembangan.

Dan kami benar-benar ingin itu berhasil untuk kami, karena ini luar biasa.

Bisakah kita memiliki sesuatu untuk diuji di go 1.11 (sedang dibekukan sekarang) atau mungkin di 1.12?
Ini sudah ditandai sebagai eksperimental. Dan saya pikir semakin banyak orang mengujinya dalam pengembangan nyata, semakin berharga umpan baliknya.

Saya membaca tentang masalah tentang paket berversi. Untuk satu skenario sederhana, jika saya menulis perpustakaan yang mengatakan gunakan dep untuk parsing plist bernama foo-plist . Sebagai konsekuensi dari parsing, pustaka plist itu mengekspos tipe-tipe tertentunya sendiri. Sekarang perpustakaan ditingkatkan ke v2, dan perpustakaan saya dipaksa untuk meningkatkan ke v2 jika saya mengembalikan objek apa pun dari jenis daftar tersebut.

Ini tampaknya cukup sulit untuk dipecahkan, misalnya, jika saya ingin perpustakaan saya mendukung v1 dan v2 dari perpustakaan plist tersebut di bawah kesan proposal ini.

Di bawah npm, misalnya, perpustakaan saya dapat dengan mudah menentukan ketergantungan rekan untuk mengatakan >=1.0.0|>=2.0.0 dan terserah kepada pengguna perpustakaan saya untuk memutuskan versi plist mana yang akan digunakan. Jadi jika pengguna perpustakaan saya foo-plist juga menggunakan perpustakaan lain yang bergantung pada plist , maka jika kedua perpustakaan senang dengan plist v1 dan v2, maka pengguna dapat memilih mana yang akan sebenarnya impor. Lebih penting lagi, jika kedua perpustakaan mengekspor tipe plist, tipe tersebut akan benar-benar kompatibel.

Jika mereka akhirnya menjadi jalur impor yang berbeda, saya rasa tidak ada cara untuk mendukungnya.

@itsnotvalid foo-plist.2 dapat mengimpor foo-plist dan mengekspor ulang tipenya menggunakan alias tipe. Deskripsi bagus tentang teknik ini dapat ditemukan di sini https://github.com/dtolnay/semver-trick

Aram menjelaskan di sini tentang kesulitan mem-back-porting perubahan ke cabang (atau direktori) rilis sebelumnya. Karena referensi "sendiri" ke sumber dalam modul yang sama juga menyertakan versi di jalur impor, tambalan tidak akan diimpor dengan bersih atau seseorang mungkin secara tidak sengaja memperkenalkan impor lintas versi.

Pikiran?

Untuk lebih jelasnya, saya sepenuhnya nyaman dengan impor lintas-modul menggunakan versi di jalur impor; Saya pikir argumen Russ sangat meyakinkan. Saya kurang jelas tentang mereka untuk impor dalam modul. Saya memahami tujuan memiliki satu jalur impor untuk paket yang diberikan dalam build (terlepas dari apakah itu sedang diimpor lintas-modul atau di dalam modulnya sendiri), tetapi jika saya harus memilih, saya lebih suka memiliki solusi untuk Masalah Aram selain mempertahankan properti ini. (Juga, saya membayangkan sistem build dapat menyuntikkan versi dari file mod saat membangun modul tingkat atas, dan secara harfiah menyuntikkannya ke sumber setelah mengunduh ketergantungan modul)

@rsc apakah ada kemungkinan kita memajukan ini? Saya tidak melihat sesuatu yang besar menahan ini.

Maaf jika saya tampak tidak sabar tentang ini, tetapi ada semakin banyak alat yang bekerja pada dukungan untuk vgo dan semakin kami menunda ini, semakin akan membuat kekacauan bagi kami, pengelola alat, untuk bolak-balik dalam hal ini .

@sdboyer berencana untuk mempublikasikan tulisannya minggu ini. Saya akan mengatakan itu adil untuk menunggu mereka.

Saya pikir algoritme penyelesaian untuk memilih versi ketergantungan mana yang tidak boleh menjadi penyebab untuk memblokir seluruh proposal, yang juga berisi hal-hal seperti modul, dukungan proxy, pembuatan versi, dan sebagainya.

Dan jika nanti kami memutuskan untuk meningkatkan/mengubah algoritme untuk mengunduh dependensi ini, maka kami dapat melakukannya tanpa memengaruhi hal lain.

Saya setuju dengan @dlsniper - kami sudah benar-benar membeku, dan sudah hampir tiga bulan sejak desain vgo diperkenalkan. Jika pekerjaannya pada 1,11 tertunda lebih jauh, saya khawatir itu akan didorong kembali ke 1,12.

Posting pertama dalam apa yang akan menjadi seri akhirnya hidup . Saya minta maaf karena ini membutuhkan waktu lama untuk diterbitkan, dan akan lebih lama lagi sebelum seri ini selesai. Tapi, posting pertama memberikan gambaran luas tentang topik yang ingin saya bahas di seluruh seri, jadi orang-orang setidaknya harus bisa memahami ruang lingkup.

Singkatnya: ada banyak hal hebat tentang vgo, banyak di antaranya yang kita sebagai komunitas inginkan sejak lama. Namun, saya percaya bahwa MVS tidak sesuai untuk tujuan tertentu, dan tidak boleh diproduksi. Sayang sekali bahwa begitu banyak dari hal-hal yang kita inginkan ini telah terjadi di sekitar MVS, terutama ketika hanya sedikit dari mereka yang khusus untuk itu. saya sedang mengerjakan pendekatan alternatif, yang direferensikan untuk tujuan perbandingan di seluruh seri blog, dan akan diartikulasikan dalam posting terakhir.

Algoritme inti alternatif yang saya kerjakan kemungkinan akan cukup mudah untuk dimigrasikan go.mod ke, jadi saya tidak mengantisipasi bahwa kami akan memiliki masalah, mungkin akan memungkinkan untuk membiarkan ini berjalan apa adanya, jika file kunci terpisah telah ditambahkan yang berisi penutupan dependensi transitif, dan memiliki _yang_ dari apa yang dibaca oleh kompiler, daripada algoritme daftar build. (Ada alasan lain untuk file kunci juga, meskipun itu akan ada di pos 5.) Paling tidak, itu memberi kita katup keluar.

Namun, jika kita mengatakan MVS baik-baik saja, bahkan sebagai pengganti sementara, maka itu masuk dan mendapatkan keuntungan dari inersia. Pada saat itu, kita harus membuktikannya tidak memadai untuk @rsc (walaupun sebenarnya, dia sudah menetapkannya sebagai standar bahkan sebelum digabungkan), dan dia percaya bahwa ini adalah pernyataan yang benar tentang go get , sekarang:

Saat ini, banyak programmer kebanyakan tidak memperhatikan versi, dan semuanya bekerja dengan baik.

Mengingat semua hal di atas, ketakutan saya adalah membiarkan ini terus berlanjut sekarang akan menciptakan "generik, putaran kedua" - kecuali kali ini seputar aturan yang mengatur cara kita berinteraksi satu sama lain, bukan dengan mesin.

Namun, jika kita mengatakan MVS baik-baik saja, bahkan sebagai pengganti sementara, maka itu masuk dan mendapatkan keuntungan dari inersia.

Perhatikan, bahwa saat ini , dep memiliki keunggulan inersia (baik dengan dibangun di tempat yang sama dengan manajer versi bahasa lain dan sudah ada lebih lama dengan dukungan komunitas luas). Setidaknya bagi saya, proposal vgo masih berhasil mengatasi kelambanan ini dengan menjadi desain yang baik, didukung oleh argumen yang baik.

Saya pribadi tidak keberatan jika pembuatan versi di Go tertunda, saya lebih suka melakukan sesuatu dengan benar daripada cepat. Tapi setidaknya saat ini, vgo masih terlihat seperti solusi yang tepat bagi saya (dan AIUI banyak orang di komunitas yang menganggap ini sebagai masalah yang mendesak).

@mvdan Perubahan ini bukan tanpa akibat. Kita semua menginginkan ini, tetapi saya pikir juga bijaksana untuk meluangkan waktu ekstra untuk menghilangkan keraguan, terutama ketika orang yang mengajukan keraguan itu dengan jelas telah memikirkan masalah itu dengan jelas.

Saya terus mendengar penyebutan pembekuan dan dampaknya untuk mendapatkan pratinjau vgo di 1.11 . Apa baris resmi pada saat ini tentang apakah ini akan diintegrasikan untuk 1.11 ? Masalah ini bagi saya tampaknya sangat tenang mengingat potensi dampaknya.

@sdboyer apa posisi Anda tentang apakah ini harus digabung menjadi 1.11 mengingat Anda hanya _just_ secara resmi menyatakan, secara publik, posisi Anda di MVS?

Jika ini tidak berhasil menjadi 1.11 , maka ini tidak akan tersedia secara resmi untuk pratinjau hingga 1.12 pada Februari 2019 dan dirilis secara resmi hingga setidaknya 1.13 pada bulan Agustus 2019. Ini menempatkan rilis potensial paling awal 18 bulan setelah @rsc pertama kali mulai membahasnya. Tentu saja kita tidak perlu terburu-buru, tetapi seperti yang dinyatakan @Merovius di atas, banyak orang, termasuk saya sendiri, menganggap tanggapan resmi terhadap manajemen ketergantungan sebagai masalah "mendesak". Menunggu 18 bulan sepertinya berlebihan.

Tampaknya dep akan menjadi respons resmi dan kami telah mengonversi repositori kami ke sana (dan senang dengan hasilnya). Dengan proposal ini yang secara efektif menghentikan dep untuk penggunaan jangka panjang, namun tidak ada cara resmi untuk mulai mengintegrasikan vgo (setidaknya hingga #25069 digabungkan), kita dibiarkan dalam posisi yang tidak memuaskan karena dipaksa untuk gunakan alat (dengan dep ) yang kami tahu memiliki masa simpan yang sangat terbatas.

FWIW, saya benar-benar berpikir bahwa kita harus bergerak maju dengan ini dengan mengintegrasikan vgo sebagai proposal di 1.11 dan menyertakan #25069 di 1.11 (dan sebagai rilis patch ke 1.9 dan 1.10 setelah rilis 1.11 ).

Sejujurnya saya tidak mengerti implikasi penuh dari MVS dan kekhawatiran @sdboyer tentang hal itu. Namun, mengingat pengalamannya di bidang ini, saya pikir kekhawatiran itu patut mendapat pertimbangan serius. Yang mengatakan, jika dia bergabung dengan mengintegrasikan vgo dengan MVS di 1.11 (sambil memahami bahwa proposal [masih berkembang], jika diterima [untuk 1.12 ], tidak boleh merusak modul dirancang awalnya untuk MVS), maka saya tidak melihat alasan untuk tidak bergerak maju.

Saya juga ingin berterima kasih kepada @rsc untuk proposal ini. Saya menghargai bahwa Go tidak hanya menyalin pendekatan alat lain dan mencoba mengatasi masalah ini dengan cara yang tampaknya idiomatis. Meskipun manajemen ketergantungan tidak pernah menyenangkan, tampaknya, dengan proposal ini, Go memiliki potensi untuk mendorong industri ke depan dan bahkan mungkin melompati sistem yang saat ini dianggap terbaik.

Sekadar menambahkan $.02 saya, pendapat saya adalah bahwa MVS adalah momen "ah ha" untuk manajemen ketergantungan. Saya menghargai jumlah pemikiran yang telah dimasukkan orang ke arah itu, tetapi tetap yakin bahwa MVS adalah tempat yang harus dituju.

Saya terutama setuju dengan poin yang dikemukakan orang lain: "perbaikan keamanan otomatis" adalah mimpi terbaik dan sekaleng besar cacing paling buruk.

Selain itu, saya dengan @joshuarubin : tanggapan resmi terhadap manajemen ketergantungan adalah masalah yang mendesak. Yang lain berkomentar bahwa kami dapat bergerak maju dengan MVS sekarang dan nanti berubah ke solusi lain jika diperlukan; jika itu memang mungkin, saya pikir itu cara yang lebih baik.

Saya mengusulkan untuk memisahkan versi utama dari jalur impor dengan cara berikut. (Saya percaya bahwa saya telah memperhitungkan alasan dalam vgo-import dan bahwa saya tidak menurunkan pencapaian vgo yang dinyatakan di sana.) Ini terinspirasi oleh gagasan dari #25069 bahwa go build di Go 1.9 dan 1.10 harus belajar untuk menginterpretasikan jalur impor secara kreatif (dengan menghapus bagian versi); dalam proposal saya go build lama tidak berubah, tetapi vgo mempelajari trik serupa.

Secara sintaksis, satu-satunya perubahan adalah:

1. Dalam file .go , import "repo/v2/pkg" tetap import "repo/v2/pkg" jika v2 adalah direktori, tetapi sebaliknya menjadi import "repo/pkg" . Ini menjaga kompatibilitas dengan go get saat ini.
2. Dalam file go.mod , module "repo/v2" tetap sama jika berada di subdirektori v2 , tetapi menjadi module "repo" jika berada di level atas. (Ini adalah awalan impor kanonik.)
3. Dalam file go.mod , Anda juga dapat menulis require repo v2.3.4 as repo2 . Kemudian dalam file .go Anda akan menggunakan import "repo2/pkg" (atau import "repo2/v2/pkg" jika v2 adalah direktori). Ini tidak akan dapat diimpor oleh go get saat ini (kecuali jika Anda menggunakan sesuatu seperti require github.com/owner/project v2.3.4 as gopkg.in/owner/project.v2 ), tetapi ini hanya diperlukan ketika Anda ingin menggunakan beberapa versi utama dalam modul yang sama dan ketergantungan tidak simpan versi utama di subdirektori, yang tidak dapat didukung oleh go get saat ini.

Secara teknis ini memungkinkan Anda untuk menulis go.mod dengan:

require repo v1.0.0
require repo v1.1.1 as repo1
require repo v2.2.2 as repo2
require repo v2.3.3 as repo3

tetapi pemilihan versi minimal akan menyelesaikan ini sehingga repo dan repo1 merujuk ke repo di v1.1.1 , dan repo2 dan repo3 di v2.3.3 . Saya tidak tahu apakah aliasing ini harus diizinkan atau dilarang.

Keuntungan:

• kode module-aware akan kompatibel dengan go get saat ini, bahkan setelah v2.0.0; Akibatnya:
  
  
  
  • tidak perlu membuat go get minimal modul sadar (#25069)
  
  
  • proyek yang melewati v2.0.0 tidak harus merusak kompatibilitas dengan modul-tidak sadar go get
  
  
• proyek tidak perlu menunggu dependensinya menjadi modul sebelum menjadi modul itu sendiri [1]
• tidak perlu mencela proyek modul-tidak sadar atau untuk mencegah penulis memulai proyek modul-tidak sadar baru
• lebih mudah untuk mempertahankan dukungan untuk alur kerja tanpa versi dari go get saat ini (dijelaskan di sini dan di atas )

Kekurangan:

• mungkin tidak nyaman untuk menepati janji bahwa file go.mod yang sudah ditulis akan terus berfungsi (kecuali file modul baru dinamai berbeda dari go.mod )

Ambivalensi:

• jalur impor yang sama dalam modul yang berbeda dapat merujuk ke versi utama yang berbeda
  
  
  
  • bagus: lebih mudah untuk mempertahankan v2.0.0 yang lalu dan pada perubahan versi utama
  
  
  • buruk: Anda tidak tahu versi utama mana yang Anda gunakan tanpa melihat go.mod
  
  
• modul dapat menentukan awalan impor sewenang-wenang untuk digunakan dalam kode mereka
  
  
  
  • beberapa pengguna akan memilih untuk mengimpor semuanya dengan nama pendek (misalnya import "yaml" dengan require gopkg.in/yaml.v2 v2.2.1 as yaml )
  
  

[1] Saat ini vgo dapat mendukung dependensi non-modular dengan benar hanya selama tidak ada dependensi transitif non-modular dari sebuah modul yang melewati v2.0.0. Jika tidak, proyek harus menunggu semua dependensi yang secara tidak langsung bergantung pada proyek yang melewati v2.0.0 untuk menjadi modul.

Saya telah melakukan analisis file Gopkg.toml yang dapat saya temukan dari paket di https://github.com/rsc/corpus dan menulis ringkasan di https://github.com/zeebo/dep-analysis. Berdasarkan data di sana, sepertinya tidak banyak bukti bahwa vgo tidak akan mampu menangani hampir semua use case yang teridentifikasi.

Saya sangat berharap bahwa ini akan membantu mengurangi rasa takut di masyarakat, dan membantu mencapai kesepakatan bahwa kita harus melanjutkan proposal apa adanya, mengingat bahwa akan ada tambahan 6 bulan untuk mendapatkan pengalaman nyata dengan alat tersebut, dan membuat perubahan yang diperlukan untuk memperbaiki masalah yang mungkin timbul.

Jika saya mengutip Anda:

Hampir setengah dari semua kendala sebenarnya bukan kendala sama sekali: mereka menunjuk ke cabang master.

Ini mungkin karena hanya master yang ada tanpa tag atau "cabang bernama seperti v2, v3" Jika itu masalahnya, maka perbandingannya tidak adil karena Anda tidak punya pilihan!

@mvrhov Saya tidak yakin apa yang Anda maksud dengan "tidak adil". Tampaknya bagi saya, vgo dan dep akan menangani kasus itu dengan baik. Atau lebih tepatnya, alternatif realistis apa pun harus menangani kasus itu dengan baik. Khususnya: Jika belum ada versi yang dirilis, di dunia vgo mereka bisa saja ditandai v1.0/v0.x dan tidak diperlukan perubahan pada jalur impor apa pun (keistimewaan utama vgo) yang diperlukan.

Inti dari analisis, sejauh yang saya tahu, adalah untuk mencoba dan memperkirakan rasa sakit dunia nyata yang disebabkan oleh pendekatan yang berbeda. Saya tidak melihat bagaimana kasus ini menimbulkan rasa sakit yang sebenarnya bagi siapa pun.

Proposal ini telah terbuka dengan diskusi aktif selama lebih dari dua bulan: @rsc & @spf13 telah melakukan sesi umpan balik dan mengumpulkan masukan berharga dari komunitas yang menghasilkan revisi proposal. @rsc juga mengadakan pertemuan mingguan dengan @sdboyer untuk mendapatkan umpan balik lebih lanjut. Ada umpan balik berharga yang diberikan pada proposal yang menghasilkan revisi tambahan. Umpan balik ini semakin banyak pada implementasi yang menyertainya daripada proposal. Setelah peninjauan yang cukup lama, kami merasa bahwa inilah saatnya untuk menerima proposal ini dan membiarkan ekosistem luas pelaksana alat Go mulai membuat penyesuaian penting sehingga basis pengguna kami dapat memiliki pengalaman terbaik.

Ada dua keberatan dari proposal ini yang kami rasa harus kami sampaikan:

1. Proposal tersebut akan mengharuskan orang untuk mengubah beberapa praktik mereka seputar penggunaan dan pelepasan perpustakaan.
2. Proposal gagal memberikan solusi teknis untuk semua kemungkinan skenario yang mungkin timbul yang melibatkan ketidaksesuaian.

Ini akurat dalam pengamatan mereka tetapi bekerja sebagaimana dimaksud. Penulis dan pengguna kode _will_ harus mengubah beberapa praktik mereka seputar penggunaan dan pelepasan pustaka, sama seperti pengembang telah mengadaptasi detail Go lainnya, seperti menjalankan gofmt. Mengubah praktik terbaik terkadang merupakan solusi yang tepat. Demikian pula, vgo tidak perlu menangani semua kemungkinan situasi yang melibatkan ketidakcocokan. Seperti yang ditunjukkan Russ dalam pembicaraannya baru-baru ini di Gophercon Singapore , satu-satunya solusi permanen untuk ketidakcocokan adalah bekerja sama untuk memperbaiki ketidakcocokan dan memelihara ekosistem paket Go. Solusi sementara di alat seperti vgo atau dep hanya perlu bekerja cukup lama untuk memberikan waktu kepada pengembang untuk memecahkan masalah sebenarnya, dan vgo melakukan pekerjaan ini dengan cukup baik.

Kami menghargai semua umpan balik dan semangat yang Anda berikan untuk masalah kritis ini. Proposal telah diterima.

— Komite Peninjau Proposal Go

Untuk menambah warna pada catatan, pertemuan mingguan dengan @sdboyer tidak boleh dianggap sebagai dukungan. Sam baru-baru ini mulai menulis tentang masalah dengan MVS bersama dengan hal-hal yang dia sukai tentang vgo . Saya menambahkan ini untuk memastikan tidak ada miskomunikasi dengan orang lain yang datang. Jika Anda ingin pendapatnya, silakan baca kata-katanya. Pendapat saya adalah bahwa mereka mengandung cukup banyak ketidaksepakatan dengan pendekatan yang dimaksudkan saat ini.

@mattfarina FWIW, saya membaca kalimat itu lebih sebagai "kami menyadari kritiknya (karena dia mengungkapkannya secara pribadi) dan itu tidak mengubah pendapat kami". Sangat disesalkan, bahwa pendapat dan argumennya tidak dipublikasikan pada saat ini.

Rasanya tidak bertanggung jawab untuk menerima proposal sementara masih ada kekhawatiran mendasar yang belum terselesaikan tentang pendekatan tersebut. Konsensus antara penulis dan pakar domain komunitas @sdboyer tampaknya merupakan standar minimum yang masuk akal untuk dicapai sebelum proposal dianggap diterima.

@merovius Beberapa dari kami telah berbagi pendapat secara publik dan pribadi. Beberapa orang merasa bahwa masalah yang diangkat tidak ditanggapi (terkadang dengan kasar) daripada diberikan solusi yang memadai. Saya mulai berbagi masalah praktis secara publik sehingga kami dapat mencoba menyelesaikannya. Sebagai contoh, hari ini saya membagikan beberapa detail tentang masalah praktis di sini . Catatan tambahan yang lucu, ini ada di halaman depan berita peretas sekaligus ini ditandai sebagai diterima.

@peterbourgon Sebagai orang yang melakukan survei Manajemen Ketergantungan Go dan yang bekerja di Glide di mana saya mendengarkan kebutuhan yang dimiliki orang dan mencoba membuatnya berhasil, saya dapat menunjukkan masalah praktis (bukan hanya opini). Artinya, saya dapat mencocokkan keinginan, kebutuhan, dan harapan pengguna dengan solusi untuk masalah tersebut. Kekhawatiran saya adalah ketidakcocokan untuk jalur vgo saat ini. Ada kebutuhan yang tidak terpenuhi dan masalah pragmatis karena perbedaan cara orang melakukan manajemen ketergantungan.

Cara mudah untuk mulai mengurangi kekhawatiran saya adalah membuat vgo berfungsi untuk Kubernetes demi kepuasan Tim Hockins.

Cara mudah untuk mulai mengurangi kekhawatiran saya adalah membuat vgo berfungsi untuk Kubernetes demi kepuasan Tim Hockins.

Jadikan vgo berfungsi untuk Kubernetes hari ini atau buat vgo berfungsi untuk Kubernetes di tahun-tahun mendatang? Seperti yang saya pahami, salah satu ketidaksepakatan desain mendasar antara vgo dan dep adalah apakah kita perlu bekerja dengan ekosistem seperti yang ada saat ini (asumsi dep) atau apakah kita dapat mengubah komunitas untuk melakukan rilis yang ditandai & menjaga kompatibilitas (asumsi vgo) .

Jadi mungkin saja vgo tidak berfungsi untuk Kubernetes yang menggunakan banyak ketergantungan untuk beberapa waktu, hingga norma komunitas Go berubah.

@mattfarina Tentu. Secara pribadi, saya merasa sangat frustasi untuk melukis ini sebagai "steamroll", meskipun. @sdboyer sebagian besar telah abstain dari diskusi publik selama berbulan-bulan dan masih belum ada argumen nyata dan konkret darinya. Dia punya alasan dan itu wajar. Tetapi konsensus masih membutuhkan diskusi dan setidaknya sejauh menyangkut catatan publik, saya pribadi tidak mengetahui masalah apa pun yang diangkat dan diabaikan (belum membaca posting Anda).

Sejauh yang saya ketahui, setiap diskusi berlangsung di balik pintu tertutup. Dan mengingat bahwa kami tidak memiliki informasi apa pun, saya akan menganggap adil untuk mengasumsikan bahwa kedua belah pihak diberikan pertimbangan yang sesuai.

@bradfitz SemVer digunakan oleh paket Go hari ini, umumnya di PHP, di node.js, di Rust, dan dalam banyak bahasa lainnya. Ini adalah hal yang cukup umum. Saya telah mengalami masalah di seluruh bahasa ini dan lebih banyak lagi di mana paket rusak dari masalah kompatibilitas SemVer. Kadang sengaja dan kadang tidak sengaja. Apa yang akan Go lakukan secara berbeda untuk menghindari masalah yang ada dalam semua bahasa lain ini karena orang bisa salah?

Jika kita tidak dapat mengartikulasikan bahwa itu adalah asumsi buruk bahwa kompatibilitas akan selalu dipertahankan dan pengembang tidak boleh memiliki kenop yang dapat diakses oleh mereka untuk menyetelnya dan meneruskan informasi itu ke pohon ketergantungan.

Saya pikir semua orang akan setuju: situasi saat ini dengan manajemen ketergantungan sangat buruk, dalam bahasa/platform apa pun. Saya percaya @bradfitz menjelaskan dengan benar poin utama konflik. Mungkin vgo tidak akan berhasil, tetapi bagi saya jelas kita harus mengubah sesuatu (maksud saya tidak hanya di Go, tetapi secara umum), dan vgo terlihat sangat menjanjikan untuk dicoba.

@mattfarina Kami berencana untuk mencoba menerapkan layanan yang secara otomatis akan mengontrol kompatibilitas yang benar-benar dipertahankan. Mengintegrasikannya dengan godoc.org, menyediakan lencana untuk README, menggunakannya sebagai proxy untuk go get - ada banyak cara bagaimana kita dapat mencoba membuatnya bekerja dengan cukup baik. Tentu, @sdboyer benar tentang kompatibilitas API tidak menjamin kompatibilitas yang sebenarnya, tapi itu awal yang baik dan harus bekerja cukup baik dalam banyak kasus.

Jadi mungkin saja vgo tidak berfungsi untuk Kubernetes yang menggunakan banyak ketergantungan untuk beberapa waktu, hingga norma komunitas Go berubah.

Harapan bukanlah strategi, terutama ketika perilaku dan harapan yang ada sudah mapan. Go mungkin memiliki token inovasi untuk dibelanjakan di sini jika kami mengadakan diskusi ini lima tahun yang lalu, dan hal-hal lebih dapat dipengaruhi. Tetapi sebagai konsekuensi dari mengabaikan masalah begitu lama, tampak jelas bagi saya bahwa alat apa pun yang diusulkan sekarang harus memenuhi pengguna di tempat mereka berada.

Apa yang akan Go lakukan secara berbeda untuk menghindari masalah yang ada dalam semua bahasa lain ini karena orang bisa salah?

Kami telah mendiskusikan semacam perintah go release yang keduanya memudahkan rilis/penandaan, tetapi juga memeriksa kompatibilitas API (seperti pemeriksa go tool api Go-internal yang saya tulis untuk rilis Go). Mungkin juga dapat menanyakan godoc.org dan menemukan pemanggil paket Anda dan menjalankan pengujian mereka terhadap versi baru Anda juga pada waktu pra-rilis, sebelum tag apa pun didorong. dll.

temukan penelepon paket Anda dan jalankan pengujian mereka terhadap versi baru Anda juga pada waktu pra-rilis, sebelum tag apa pun didorong. dll.

Ini tidak terlalu praktis bagi siapa saja yang bukan Google.

Ini tidak terlalu praktis bagi siapa saja yang bukan Google.

Dengan semua penyedia cloud mulai menawarkan container-as-a-service pay-by-the-second, saya tidak melihat alasan kami tidak dapat menyediakan ini sebagai alat open source yang dapat dijalankan oleh siapa saja dan membayar $0,57 atau $1,34 yang mereka butuhkan untuk menjalankan bazillion tes atas sekelompok host selama beberapa menit.

Tidak banyak saus rahasia Google dalam hal menjalankan tes.

Dengan semua penyedia cloud mulai menawarkan container-as-a-service pay-by-the-second, saya tidak melihat alasan kami tidak dapat menyediakan ini sebagai alat open source yang dapat dijalankan oleh siapa saja dan membayar $0,57 atau $1,34 yang mereka butuhkan untuk menjalankan bazillion tes atas sekelompok host selama beberapa menit.

Ini memerlukan akun dengan penyedia cloud tertentu, mengharuskan Anda menerima persyaratan layanan penyedia cloud tertentu (yang mungkin atau mungkin tidak dapat Anda lakukan karena alasan hukum, bahkan jika sebagian besar dunia memperlakukan ini seolah-olah tidak masalah), mengharuskan Anda tinggal di area yang layanan penyedia cloud (mis. jika Anda berada di Iran dan penyedia cloud berada di Amerika Serikat, Anda mungkin tidak dapat menggunakannya karena undang-undang ekspor), dan mengharuskan Anda memiliki uang untuk dibelanjakan untuk membayar penyedia cloud (mungkin setiap kali Anda melakukan rilis). Mungkin tidak banyak uang, tetapi itu tidak berarti semua orang akan mampu membayarnya. Jika kami ingin Go menjadi inklusif dan dapat digunakan oleh beragam audiens, ini sepertinya bukan solusi yang baik.

/dua sen

@SamWhited MeteorJS telah bekerja dengan galaksi ini, perintah meteor publish bawaan untuk menjalankan proyek Anda di penyedia cloud. Mungkin saya salah memahami masalah yang diajukan, tetapi ayunan mereka tampaknya baik-baik saja.

@bradfitz Bagaimana jika API tidak berubah tetapi perilaku di baliknya berubah? Itu adalah kasus yang pecah dari SemVer dan berdampak pada mereka yang mengimpornya. Bagaimana Anda mendeteksi situasi ini? Saya bertanya karena saya sudah mengalaminya lebih dari satu kali.

alat open source yang dapat dijalankan oleh siapa saja dan membayar $0,57 atau $1,34 yang mereka perlukan untuk menjalankan tes bazillion pada sekelompok host selama beberapa menit.

Ini sekarang menyentuh biaya. Ini mungkin terasa baik untuk orang-orang di kota teknologi di AS. Bagaimana dengan orang-orang di Afrika, Amerika Tengah, atau tempat lain yang tersebar secara global. Bagaimana alat seperti ini umumnya dapat diakses di luar lingkaran "elit teknologi"?

Dan, bagaimana dengan semua kasus tidak melakukan pekerjaan cloud publik? Di tempat (banyak orang melakukannya) atau kepemilikan dan memiliki masalah kepercayaan. Bagaimana hal ini akan bekerja untuk mereka? Jika Anda memiliki alat internal, Anda mungkin tidak ingin membocorkan ke layanan publik impor apa yang Anda gunakan. Katakanlah Anda mendapatkan impor dari GitHub tetapi layanan ini berjalan di Google. Apakah orang merasa baik-baik saja menyerahkan pohon ketergantungan mereka ke Google? Sekelompok tidak akan.

Mungkin juga dapat menanyakan godoc.org dan menemukan pemanggil paket Anda dan menjalankan pengujian mereka terhadap versi baru Anda juga pada waktu pra-rilis, sebelum tag apa pun didorong. dll.

Mari kita ambil Kubernetes sebagai contohnya. Seseorang menulis paket yang diimpor ke Kubernetes. Jadi alat harus mendapatkannya dan menjalankan semua tes. Bagian-bagiannya dirancang untuk berjalan di Windows dan POSIX. Bisakah kita menguji multi-OS/multi-arch (karena Go menangani itu). Seperti apa bentuknya (dan biayanya)?

--

Saya pikir alat seperti ini dapat berguna. Saya tidak bermaksud agar orang-orang berpikir sebaliknya. Saya hanya tidak melihat bagaimana mereka memecahkan masalah bagi banyak orang. Mereka tidak cukup praktis atau tidak cocok untuk setiap pengaturan.

Rasanya seperti kami mencoba memecahkan masalah matematika dengan batasan yang diketahui dan dapat dikontrol. Tapi, orang-orang berantakan sehingga kami membutuhkan solusi yang toleran terhadap kesalahan.

Mengutip @technosophos sebelumnya hari ini:

"pengelola versi sebenarnya bukan alat untuk kompiler atau tautan atau apa pun... pengelola versi adalah untuk orang yang berkolaborasi."

Untuk apa nilainya, dia menulis lebih dari satu manajer ketergantungan, mempelajari yang lain, dan berbicara dengan orang-orang yang telah menulis lebih banyak lagi.

Rasanya tidak bertanggung jawab untuk menerima proposal sementara masih ada kekhawatiran mendasar yang belum terselesaikan tentang pendekatan tersebut. Konsensus antara penulis dan pakar domain komunitas @sdboyer tampaknya merupakan standar minimum yang masuk akal untuk dicapai sebelum proposal dianggap diterima.

Sekadar untuk menambahkan sedikit di sini: kami memiliki sejarah seputar pengemasan yang tidak standar dan kurang optimal (ekosistem go get ). Akan lebih baik untuk menyerah pada manajer paket standar daripada memiliki go get lain yang dirilis yang mendorong orang ke arah praktik buruk atas nama kompatibilitas dengan alat "standar". Sebagai seseorang yang telah menggunakan Go sejak dirilis ke publik, saya merasa percakapan ini membuat frustrasi dan mengecewakan karena tampaknya kepemimpinan tim Go belum mempelajari pelajaran dari kesalahan yang dibuat dengan go get (nee goinstall ).

Ada masalah yang masuk akal dan praktis yang telah disuarakan tentang proposal ini. Kita harus mengubah proposal untuk mengatasi mereka tidak hanya mengatakan: "bekerja sebagaimana dimaksud." Jika kita tidak bisa melakukannya dengan benar untuk 1.11 atau 1.12 atau 1.13 maka kita harus menunggu sampai bisa dilakukan dengan benar. Proposal ini mengusulkan sistem yang berperilaku sangat berbeda dari kebanyakan sistem lain dan tidak dalam cara yang baik.

Alasan yang memotivasi di balik MVS tampaknya adalah bahwa pendekatan tradisional adalah NP-Complete. Saya menemukan bahwa motivasi yang sangat miskin. Ketika berhadapan dengan masalah NP-Lengkap pertanyaan utamanya adalah: "Seberapa sering contoh sulit muncul." Dengan manajemen paket, jawabannya tampaknya "sangat jarang". Kita tidak boleh puas dengan rumusan masalah yang tidak lengkap dan tidak membantu hanya untuk menghindari label NP-HARD pada masalah tersebut.

Sebagian besar poin konkret telah disuarakan oleh orang lain yang lebih dekat dengan masalah ini ( @sdboyer @peterbourgon @mattfarina dll ...). Keluhan utama saya adalah bahwa kami menerima proposal ini ketika poin-poin konkret ini belum ditangani secara memadai.

@SamWhited , Anda mempermasalahkan fitur opsional dari desain hipotetis. Pengguna hipotetis yang tidak memercayai penyedia cloud mana pun atau tidak dapat menggunakan penyedia cloud apa pun di dalam firewall negara mereka atau tidak ingin membayar selalu dapat menjalankan pengujian (atau sebagian kecilnya) di mesin mereka sendiri dalam semalam. Atau cukup gunakan pemeriksaan tanda tangan go release , yang memberi Anda 95% perjalanan ke sana secara gratis.

@mattfarina , @SamWhited , mari pindah diskusi ke https://github.com/golang/go/issues/25483.

@mattfarina

Saya telah mengalami masalah di seluruh bahasa ini dan lebih banyak lagi di mana paket rusak dari masalah kompatibilitas SemVer. Kadang sengaja dan kadang tidak sengaja. Apa yang akan Go lakukan secara berbeda untuk menghindari masalah yang ada dalam semua bahasa lain ini karena orang bisa salah?

Masih belum jelas bagi saya, mengapa vgo dianggap berkinerja lebih buruk dalam kasus ini daripada dep. Sebaliknya, menurut saya vgo berkinerja lebih baik . Dalam posting blog Anda, Anda menyebutkan masalah khusus dengan helm, sebagai bukti kegagalan model vgo. Namun, di dunia vgo, ada dua skenario mengapa vgo memilih menggunakan v1.4.0 untuk grpc:

1. Pengembang helm memilih untuk menentukan grpc >= v1.4.0 dalam go.mod sebagai persyaratan. Dalam hal ini, mereka dapat dengan mudah mengembalikan persyaratan ini dan dengan demikian memutar kembali ke versi grpc sebelumnya yang sesuai untuk mereka.
2. Pengembang ketergantungan helm memilih untuk menentukan grpc >= v1.4.0 . Dalam hal ini, dep akan menginstal itu juga dan jika helm akan mencoba untuk memutar kembali dengan membatasi grpc < v1.4.0 dep harus serak karena persyaratan yang bertentangan.

Jadi menurut saya, vgo memecahkan masalah ini setidaknya sebaik dep. Sementara itu, di dunia yang dalam, ada opsi lain:

1. Ketergantungan transitif helm membutuhkan grpc >= v1.x.0 , dengan beberapa x < 4 , kemudian grpc merilis v1.4.0 dan dep memutuskan untuk menggunakan versi yang lebih baru saat menginstal, tanpa diminta . Dalam hal ini, helm akan rusak dan perlu berkumpul untuk melakukan rilis perbaikan bug (seperti yang dijelaskan melalui posting Anda), membuat kerja keras. Sementara itu, vgo akan mengabaikan versi baru dan semuanya akan terus berfungsi dengan baik.

Saya tampaknya mengabaikan sesuatu yang mendasar. Tapi terakhir kali saya meminta klarifikasi tentang ini di slack, saya ditangguhkan ke posting blog hipotetis di masa depan. Karenanya frustrasi saya, karena saya benar-benar tidak mengerti dari mana ide itu berasal, vgo entah bagaimana memiliki lebih banyak masalah dengan orang-orang yang melanggar semantik versi mereka daripada yang dimiliki dep.

Untuk memperjelas, ini bukan tentang dep . Ini adalah analisis tentang bagaimana MVS (vgo) berperilaku dibandingkan dengan solusi manajemen paket berbasis pemecah SAT lainnya (termasuk dep).

Contoh lain oleh Matt menyatakan sebagai berikut:

Anda adalah pengembang modul app dan Anda memiliki dua dependensi:

• grpc [>= 1.8 ]
• helm , yang memiliki ketergantungan berikut:
  
  
  
  • grpc [>= 1.0, < 1.4] (karena grpc memperkenalkan perubahan besar pada 1.4).
  
  

Kebanyakan orang tidak akan tahu tentang persyaratan ketergantungan transitif ( helm -> grpc [>= 1.0, < 1.4]) karena itu perlu disadari bahwa helm rusak ketika menggunakan grpc >= 1.4. Saya berasumsi itu bukan sesuatu yang mayoritas orang akan pedulikan atau menghabiskan waktu dan energi untuk menyelidikinya.

Jika Anda menggunakan vgo (khususnya mengandalkan MVS), Anda akan mendapatkan:

• helm
• grpc [>= 1.8 ]

Itu seharusnya merupakan kombinasi yang tidak valid (karena persyaratan helm tidak terpenuhi) dan sebagian besar manajer dep akan memberikan pesan kesalahan yang memberi tahu Anda bahwa Anda memiliki konflik (mengingat bahwa helm telah menyatakan persyaratannya di beberapa format).

Ini adalah poin kritik yang signifikan terhadap MVS dan vgo. Itu tidak ingin mengizinkan dependensi untuk menyatakan ketika mereka memiliki masalah dengan versi tertentu untuk menghindari kebutuhan penyelesaian SAT penuh . Anda dapat merujuk ke bagian Theory dan Excluding Modules di artikel MVS untuk penjelasan lebih lanjut.

MVS tidak ingin mengakui kemungkinan ini (atau setidaknya ingin membatasi kemampuan untuk mendiktekannya ke modul saat ini) dengan asumsi bahwa SemVer selalu dihormati dan oleh karena itu ini tidak diperlukan, yang praktis tidak selalu demikian. Saya akan merujuk ke artikel Anda tentang kompatibilitas mundur untuk menunjukkan mengapa mematuhi kompatibilitas mundur itu sulit dan tidak praktis ketika dipaksa dengan cara vgo.

Solusi MVS adalah meminta pengembang modul untuk menentukan versi mana yang akan dikecualikan, mengabaikan pengetahuan yang dapat dibagikan oleh penulis dependensi tentang ketidaksesuaian ini. Dengan demikian mengalihkan tanggung jawab kepada pengembang untuk mengetahui dan melakukan logika berbelit-belit yang dilalui sebagian besar manajer dep untuk mencari tahu versi dependensi mana yang kompatibel satu sama lain (yaitu, pemecahan SAT).

Kecuali jika orang secara ajaib mulai menyesuaikan diri dengan SemVer, saya membayangkan menginstal ketergantungan saat menggunakan vgo untuk mengubah ke latihan eksentrik di mana setelah mengimpor modul Anda harus memeriksa file README untuk menyalin daftar versi yang tidak kompatibel untuk disertakan mereka di file go.mod Anda. Ingatlah bahwa pernyataan exclude hanya menggunakan satu versi saat ini.

@Merovius

Dalam posting blog @mattfarina , mereka menjelaskan peningkatan Helm ke grpc v1.4.0 dengan sengaja, yaitu dengan memperbarui go.mod . Pertanyaannya bukanlah bagaimana dep atau vgo menghindari masalah ini, melainkan bagaimana mereka memungkinkan penulis perpustakaan untuk memulihkannya. Dalam kasus dep, mereka dapat merilis patch yang mengiklankan batasan grpc<v1.4.0 . Untuk pengguna yang tidak memiliki ketergantungan lain pada grpc, ini hanya akan berfungsi. Jika pengguna telah memperbarui helm ke versi terbaru dan memiliki ketergantungan lain pada grpc>=v1.4.0 , batasan ini akan menyebabkan pembangunan mereka gagal; tidak ideal, tetapi lebih baik daripada perilaku runtime yang rusak.

Dengan vgo , apakah pengelola Helm memiliki opsi yang setara? Jika pengguna telah meningkatkan grpc ke v1.4.0 karena alasan apa pun, MVS akan selalu memilih [email protected] , Helm akan rusak, dan tidak ada yang dapat dilakukan oleh pengelola Helm (tanpa menyesuaikan perilaku yang berubah, yang sering membuang-buang waktu). Saya tidak dapat berbicara mewakili @mattfarina , tetapi begitulah cara saya membaca kekhawatiran yang diangkat dan itu adalah salah satu yang saya bagikan. Dengan dep dan sistem serupa, perpustakaan perantara dapat bertahan terhadap (atau lebih sering, pulih dari) pelanggaran kompatibilitas dengan batasan batas atas.

@ibrasho @mattfarina

Sepertinya salah satu contoh Russ dalam pembicaraan GopherconSG mencakup skenario yang sangat mirip (mungkin identik?).

Dalam posting di atas, Anda mengatakan bahwa helm tergantung pada "grpc [>= 1.0, < 1.4]". Tapi itu tidak sepenuhnya akurat. Saya pikir yang Anda maksud adalah bahwa beberapa versi helm tertentu bergantung pada "grpc [>= 1.0, < 1.4]". Katakanlah versi helm adalah 2.1.3; mungkin versi helm ini dirilis setelah grpc 1.4 (jika tidak, helm ini tidak akan diketahui menandai dirinya sendiri tidak kompatibel dengan grpc 1.4). Maksud Russ dalam pembicaraan itu adalah bahwa versi helm sebelumnya (katakanlah 2.1.2), mungkin tidak akan (belum) menandai dirinya sebagai tidak kompatibel dengan grpc 1.4.

Dengan kata lain, tugas yang memuaskan (menurut dep) akan menjadi helm = 2.1.2, grpc = 1.8. Dep dapat dengan benar memilih penetapan versi ini tanpa kesalahan, karena memenuhi semua batasan pada versi yang diberikan.

@balasanjay

Versi Helm tidak mengubah contoh secara mendasar. [email protected] mungkin mendeklarasikan ketergantungan pada [email protected] dan pengguna helm mungkin memiliki ketergantungan pada [email protected] secara langsung atau melalui beberapa paket lain. Dalam skenario ini, MVS gagal dan menginstal [email protected] dan [email protected]. Selain itu, contoh ini mengasumsikan bahwa pengguna dengan sengaja memperbarui ke [email protected] (dan dengan demikian [email protected]) dan mungkin bahkan [email protected] , [email protected] , dll sebelum masalah terungkap.

MVS dengan sengaja melarang pengecualian dari dependensi perantara untuk mencapai tujuan teoretisnya:

Implikasi negatif (X → Y, ekuivalen X ¬ Y: jika X dipasang, maka Y tidak boleh dipasang) tidak dapat ditambahkan...

Untuk contoh ini, kita perlu menyatakan, jika X= helm>= 2.1.3 diinstal maka Y= grpc>=1.4.0 tidak boleh diinstal, yang tidak dapat kita lakukan dengan desain.

Akibatnya, hanya paket tingkat atas (dengan memperbaiki kerusakan) dan pengguna tingkat bawah (dengan menambahkan pengecualian secara manual) yang memiliki jalan lain ketika aturan kompatibilitas dilanggar. Perantara seperti Helm harus bekerja dengan semua versi masa depan dari dependensi apa pun, yang, bagi saya, secara signifikan mengurangi proposisi nilai perpustakaan semacam itu.

Mungkin ini akan mendorong perilaku yang lebih baik dalam penggunaan perpustakaan yang berat seperti grpc dan aws-sdk-go karena beban penuh dari kerusakan apa pun akan dirasakan oleh semua pihak dan akan lebih sulit untuk diatasi. Namun, itu tidak selalu mudah. Bagaimana jika "kerusakan" tidak benar-benar rusak, tetapi perubahan perilaku yang sah yang memiliki konsekuensi yang tidak diinginkan bagi beberapa pengguna, tetapi bermanfaat bagi orang lain? Hal semacam itu tidak jarang dan penulis hulu akan ragu-ragu untuk mengembalikan perubahan dalam skenario itu.

Saya tidak berpikir saya hampir sejelas Russ. Biarkan saya mencoba lagi.

Awalnya, keadaan deps terlihat seperti ini.
Helm 2.1.2: grpc >= 1.0

Kemudian, grpc 1.4 dilepaskan. Pengembang Helm menyadari ada ketidakcocokan, dan mendorong versi baru Helm:
Helm 2.1.3: grpc >= 1.0, < 1.4

Saya memulai aplikasi baru yang bergantung pada Helm dan beberapa fitur baru grpc (demi argumen). Saya daftar deps berikut:
Helm >= 2.0.0
grpc >= 1,4

Klaim di atas adalah bahwa dep akan melihat konflik yang melekat, dan melaporkan kesalahan.

Tetapi Russ menunjukkan bahwa itu tidak benar, karena ada penetapan versi tanpa konflik. Secara khusus, dep dapat memilih untuk menggunakan helm 2.1.2 dan grpc 1.4. Menurut dep, ini adalah tugas yang sah, karena helm 2.1. 3 adalah yang tidak kompatibel dengan grpc 1.4, sedangkan 2.1. 2 kompatibel dengan semua grpc >= 1.0.

Dengan kata lain, dep dapat _ dengan sah_ memilih untuk "memperbaiki" konflik, dengan menurunkan versi ke versi yang belum merekam konflik. Jika Anda memiliki versi yang tidak dapat diubah, maka ini tampaknya tak terhindarkan. Oleh karena itu, tampaknya dep juga salah menangani https://codeengineered.com/blog/2018/golang-vgo-broken-dep-tree/.

@balasanjay Tentu, tetapi akhirnya Helm mengeluarkan 2.2.0 dengan fitur baru yang rapi yang Anda inginkan, dan Anda mencoba memutakhirkan, dan kemudian masalah muncul.

(Saya sangat optimis bahwa ini akan berhasil jika vgo memiliki UX yang dirancang dengan baik untuk membuat orang sadar bahwa hasil MVS mereka memiliki "konflik" dalam bentuk ini. Dengan "dirancang dengan baik" yang saya maksud adalah mendorong orang untuk berurusan dengan masalahnya alih-alih hanya baik-baik saja dengan banyak peringatan sepanjang waktu.)

Saya tentu setuju bahwa ada situasi di mana dep akan mendeteksi konflik, tetapi hanya ingin memperjelas bahwa itu _bukan_ yang disajikan dalam posting blog itu (atau setidaknya, tidak dengan persyaratan versi seperti yang disajikan saat ini).

Dan FWIW, saya pikir masuk akal untuk mempertanyakan keefektifan perlindungan jika melanggar contoh konflik yang relatif sederhana.

Sebagai catatan, saya melacak contoh Russ (hampir identik dengan yang ini, hingga tingkat yang mengesankan): https://youtu.be/F8nrpe0XWRg?t=31m28s

Re: pemilihan versi minimal, saya mengalami kesulitan mencari cara untuk mengatasi situasi berikut:

Bayangkan sebuah perpustakaan populer dalam mode maitenence, misalnya v1.2.3 telah keluar selama lebih dari setahun tanpa perubahan. Banyak perpustakaan lain bergantung padanya.
Seorang pengembang datang dan menyadari pengoptimalan kecepatan untuk dilakukan di v1.2.3. Ini mempercepat fungsi inti perpustakaan hingga 10x, tanpa perubahan API! Ini dirilis sebagai v1.3.0. Tidak ada lagi bug yang ditemukan dalam paket ini untuk tahun berikutnya.

Bagaimana orang yang bergantung pada akhirnya mendapatkan pembaruan ini? Mereka dapat bekerja dengan v1.2.3, tetapi v1.3.0 jelas lebih baik.

@daurnimator

Bagaimana orang yang bergantung pada akhirnya mendapatkan pembaruan ini?

Setiap aplikasi perlu menetapkan 1.3.0 sebagai versi minimum untuk digunakan.

Yah, betapa konyolnya hari ini! 😄.

Proposal ini telah terbuka dengan diskusi aktif selama lebih dari dua bulan

Masalah ini telah terbuka selama bertahun-tahun, dan garis waktu yang ditetapkan rsc untuk semua ini cukup pendek secara artifisial, semua hal dipertimbangkan.

Ada dua keberatan dari proposal ini yang kami rasa harus kami sampaikan:

1. Proposal gagal memberikan solusi teknis untuk semua kemungkinan skenario yang mungkin timbul yang melibatkan ketidaksesuaian.

Jika ini merupakan kiasan terhadap posisi yang telah saya uraikan kepada Russ, itu adalah karikatur yang menyesatkan. Salah satu alasan saya butuh waktu lama untuk menyusun pemikiran saya tentang topik ini adalah karena penggunaan berulang kali argumen dan pernyataan yang menyesatkan adalah...terus terang, membuat tidak stabil.

Secara harfiah tidak ada yang berpikir bahwa SEMUA skenario yang mungkin dapat dicakup. Masalahnya adalah, dan selalu, bahwa MVS hanya memecahkan masalah _ilusi_ (menghindari SAT), menciptakan masalah _baru_ sebagai gantinya yang jauh lebih penting dalam praktiknya, dan tidak dapat berfungsi secara efektif sebagai lapisan perantara di mana kita dapat beroperasi secara wajar.

Ini akurat dalam pengamatan mereka tetapi bekerja sebagaimana dimaksud. Penulis dan pengguna kode harus mengubah beberapa praktik mereka seputar penggunaan dan pelepasan pustaka, sama seperti pengembang telah beradaptasi dengan detail lain dari Go, seperti menjalankan gofmt.

Tidak ada yang terbantu dengan meremehkan tingkat perubahan yang diusulkan di sini dengan membandingkannya dengan menjalankan gofmt - mungkin satu-satunya aktivitas paling ceroboh yang kami lakukan sebagai pengembang Go.

Seperti yang ditunjukkan Russ dalam pembicaraannya baru-baru ini di Gophercon Singapore, satu-satunya solusi permanen untuk ketidakcocokan adalah bekerja sama untuk memperbaiki ketidakcocokan dan memelihara ekosistem paket Go. Solusi sementara di alat seperti vgo atau dep hanya perlu bekerja cukup lama untuk memberikan waktu kepada pengembang untuk memecahkan masalah sebenarnya, dan vgo melakukan pekerjaan ini dengan cukup baik.

Mari kita perjelas - yang penting adalah _komunitas_. Kita. Orang-orang yang menghasilkan ekosistem perangkat lunak. Kami mencapai ekosistem yang lebih baik dengan membuat alat yang membantu kami menggunakan token terbatas kami untuk kolaborasi yang bermanfaat - bukan dengan membuat alat rapuh yang menghukum kami karena berpartisipasi sejak awal.

@Merovius :

Saya ditangguhkan ke posting blog hipotetis di masa depan. Karenanya frustrasi saya, karena saya benar-benar tidak mengerti dari mana ide itu berasal, vgo entah bagaimana memiliki lebih banyak masalah dengan orang-orang yang melanggar semantik versi mereka daripada yang dimiliki dep.

Mengumpulkan semua argumen ini membutuhkan waktu, dan itu bukan pekerjaan harian saya. Saya bertujuan untuk menyelesaikan malam ini, tetapi saya masih dalam izin pengeditan terakhir saya. Besok pagi...? Tidak ada yang diatur dalam batu!

Masalahnya adalah, dan selalu, bahwa MVS hanya memecahkan masalah ilusi (menghindari SAT), ...

Dengan hormat, IMHO solusi SAT adalah non-solusi, oleh karena itu bagi saya, MVS memecahkan masalah yang sangat nyata.

IMHO solusi SAT adalah non-solusi, oleh karena itu bagi saya, MVS memecahkan masalah yang sangat nyata.

Ingin memahami alasan di balik itu, jika memungkinkan?

Masalah ini telah terbuka selama bertahun-tahun, dan garis waktu yang ditetapkan rsc untuk semua ini cukup pendek secara artifisial, semua hal dipertimbangkan.

Saya melihat dua ide yang jelas bertentangan di sini. Survei telah berulang kali menunjukkan bahwa manajemen ketergantungan membutuhkan solusi lebih cepat daripada nanti. Namun waktu enam bulan tidak cukup untuk meninjau dan menyetujui proposal.

Saya mengerti bahwa kita tidak harus memilih solusi pertama yang akan diterapkan. Tapi waktu adalah salah satu faktornya. Kontra-proposal untuk vgo belum didefinisikan dengan baik, dan kemungkinan besar akan memakan waktu bertahun-tahun untuk terwujud. Saya akan memilih vgo di Go 1.11 daripada solusi berbasis SAT yang luar biasa di Go 1.14 kapan saja.

Ini juga mengasumsikan bahwa apa yang diimplementasikan vgo diatur dalam batu. Untuk semua yang kita tahu, vgo dapat berubah secara signifikan selama jendela 1,12 dan 1,13.

Ingin memahami alasan di balik itu, jika memungkinkan?

Itu adalah alasan yang sama di balik pemilihan regexp Go daripada PCRE, yaitu. tidak membiarkan program bergantung pada algoritme yang memiliki kompleksitas kasus terburuk kuadratik/eksponensial.

Kita harus ingat bahwa vgo hanya akan menggantikan go get tidak lebih tidak lebih. Kita harus membandingkan vgo dengan go get dan bukan vgo dengan sesuatu yang tidak ada. "Lebih buruk lebih baik"! Sekarang mari kita fokus pada detail implementasi.

FWIW, IMO sepenuhnya mungkin untuk memperkenalkan batas atas tanpa memiliki pemecah SAT penuh - solusi yang dihasilkan tidak mungkin optimal atau untuk menjamin bahwa solusi yang ada akan ditemukan. Jika perlu, Anda bisa

1. Memungkinkan untuk menentukan batas atas
2. Abaikan mereka saat menyelesaikan melalui MVS
3. Periksa solusi yang ditemukan terhadap semua batas dan parau jika tidak cocok (ini adalah perbedaan utama: Pendekatan tradisional akan mencoba menemukan solusi yang berbeda sebagai gantinya)

Ini berarti Anda mendapatkan keuntungan dari MVS (algoritma sederhana tanpa runtime patologis), menjaga kemungkinan untuk menandai ketidaksesuaian dan mendeteksinya secara statis tetapi Anda memberikan jaminan untuk selalu menemukan solusi jika ada. Meskipun dapat dikatakan, bahwa solusi yang akan Anda temukan, sebenarnya bukanlah solusi, karena ketidakcocokan masih ada, hanya tidak diketahui oleh algoritme.

Jadi setidaknya bagi saya, tampaknya sangat mungkin untuk memperbaiki beberapa cara untuk mendapatkan batas atas ke MVS. Saya masih tidak yakin itu benar-benar diperlukan, tetapi jika itu terjadi, itu selalu dapat ditambahkan nanti. Membuat pernyataan "MVS pada dasarnya tidak layak" bermasalah. Tapi saya mungkin masih salah memahami masalahnya. Dan mungkin ada skenario kegagalan yang menggambarkannya dengan lebih baik?

@sdboyer Jangan khawatir. Seperti yang saya katakan, saya sepenuhnya mengerti bahwa ini bukan pekerjaan harian Anda dan saya menghargai waktu yang Anda luangkan untuk berpartisipasi. Ini masih masalah praktis "jika kita tidak tahu argumennya, kita tidak bisa membicarakannya". Saya dapat membayangkan bahwa Anda sama frustrasinya dengan seluruh situasi seperti saya :)

Itu adalah alasan yang sama di balik pemilihan regexp Go daripada PCRE, yaitu. tidak membiarkan program bergantung pada algoritme yang memiliki kompleksitas kasus terburuk kuadratik/eksponensial.

@cznic Saya berpendapat bahwa manajemen ketergantungan bukan hanya masalah teknis, ini terkait dengan kendala dan pertimbangan sosial. Jadi saya tidak yakin membandingkannya dengan ekspresi reguler (masalah implementasi teknis murni) dan mendukung algoritma yang pada dasarnya berdasarkan kompleksitas waktu adalah pendekatan yang adil.

Saya melihat beberapa orang menyukai MVS karena lebih sederhana dan lebih mudah untuk dipikirkan dan itu merupakan pertimbangan yang dapat dimengerti jika itu menyelesaikan aspek lain dari masalah yang dihadapi.

Saya bertanya-tanya apakah orang memiliki alasan lain untuk memilihnya daripada algoritma berbasis SAT.

Saya bertanya-tanya apakah orang memiliki alasan lain untuk lebih memilihnya daripada algoritma berbasis SAT.

@ibrasho MVS tidak memerlukan file kunci.

Saya bertanya-tanya apakah orang memiliki alasan lain untuk memilihnya daripada algoritma berbasis SAT.

Secara pribadi, alasan saya adalah

1. Ini menyatukan file kunci dan manifes menjadi satu file, yang sebagian besar dapat diedit oleh komputer. Berarti lebih sedikit noise sambil tetap dapat direproduksi (atau "high-fidelity") dibangun dalam kasus umum. AFAICT ini adalah sesuatu yang unik untuk MVS. Karena salah satu frustrasi utama saya dengan manajer paket lain adalah kerja keras karena harus mengedit file manifes, ini sangat besar bagi saya.
2. Perbaikan bertahap akan lebih mudah/mungkin. Karena saya sangat percaya pada pendekatan ini untuk memecahkan masalah pengembangan terdistribusi, ini juga penting bagi saya.
3. Ini dapat membantu ekosistem untuk secara kolektif tetap dekat dengan HEAD untuk sebagian besar perpustakaan. Ini sebagian besar spekulasi dan agak tergantung pada perkakas yang tersedia. Tetapi jika "tarik semuanya ke versi terbaru" cukup sederhana, itu dapat meningkatkan irama yang dengannya versi perpustakaan yang lebih baru diuji satu sama lain dalam produksi.
4. Ini mencapai semua ini sambil mempertahankan atau melampaui kualitas yang diinginkan dari pendekatan lain, AFAICT. Upgrade hanya terjadi jika diinginkan. Dan paket biner akan terus dibangun bahkan jika beberapa dependensinya rusak dalam versi baru, memberikan waktu kepada penulis untuk memperbaikinya.

Terutama bagian terakhir ini agak ironis. Karena kualitas yang tepat ini digambarkan sangat penting dalam posting terakhir @sdboyer - tetapi pada titik ini, saya masih percaya vgo lebih baik dalam hal ini daripada pendekatan tradisional.

@Merovius
"Ini menyatukan file kunci dan manifes menjadi satu file"

• ini tidak sepenuhnya benar karena manifes tersebar secara efektif di seluruh file Anda. Pernyataan impor secara efektif bertindak sebagai manifes.

@docmerlin Ketika saya mengatakan "manifest", maksud saya file yang mencantumkan semua modul yang Anda andalkan dengan versi yang sesuai (khususnya, ini berisi lebih banyak informasi daripada pernyataan impor, jika tidak, Anda tidak akan membutuhkannya). Dalam kasus vgo itu adalah go.mod , dalam kasus dep itu Gopkg.toml . Anda juga dapat menyebutnya sebagai file konfigurasi untuk pemecah ketergantungan. Jika Anda menganggap istilah yang berbeda lebih tepat, jangan ragu untuk menggantinya dengan manifes, saat Anda membaca komentar saya.

Perhatikan, bahwa cukup normal jika ada file yang mencantumkan semua dependensi dan daftar impor eksplisit (yang merupakan subset dependensi yang berpotensi ketat) per file. Secara khusus, semua manajer ketergantungan Go yang saya ketahui melakukan itu. Pendekatan lain juga menggunakan file kunci yang menjelaskan versi spesifik dan presisi yang digunakan untuk memastikan pembuatan yang dapat direproduksi. Dan fitur pembeda dari MVS yang saya maksud, adalah bahwa file ini tidak diperlukan, karena dapat diturunkan secara unik dari file manifest/dependency-solver-config/go.mod.

(dihapus + diposting ulang dari akun pribadi saya)

@cznic fokus pada kelas kompleksitas MVC vs pendekatan berbasis SAT dalam isolasi tidak masuk akal (seperti yang saya pikir @sdboyer tulis di suatu tempat -- kita terjebak membicarakannya karena itu adalah salah satu dari sedikit hal yang bisa kita lakukan nama/identifikasi).

Saran @ bradfitz di #25483 untuk mengatasi beberapa masalah dengan vgo (yang menurut saya awalnya gila tapi mungkin solusi praktis yang bagus) melibatkan menjalankan tes dari pengguna API Anda yang sewenang-wenang sebelum rilis. Ini adalah masalah lengkap NP secara umum, tetapi dalam praktiknya mungkin merupakan solusi yang bagus (seperti gps2).

Jadi di satu sisi kami memiliki algoritme manajemen paket berbasis SAT, dan di sisi lain kami memiliki algoritme di NL yang memaksa kami untuk melakukan pekerjaan NP-complete nanti (atau time out, yang akan dilakukan oleh pemecah SAT praktis mana pun untuk file kunci permusuhan).

fokus pada kelas kompleksitas MVC vs pendekatan berbasis SAT dalam isolasi tidak masuk akal ...

Saya tidak yakin dari mana istilah 'fokus' berasal. Hanya saja jika ada dua algoritma yang tersedia, kasus terburuk yang satu adalah kuadrat atau lebih buruk dan yang lainnya linier atau lebih baik, saya memilih yang belakangan dan menghindari yang pertama. Saya akan menyebutnya prinsip, bukan fokus.

... saran di #25483 untuk mengatasi beberapa masalah dengan vgo ...

Sepertinya masalah #25483 tidak terkait dengan vgo. Salah ketik?

Hanya saja jika ada dua algoritma yang tersedia, kasus terburuk yang satu adalah kuadrat atau lebih buruk dan yang lainnya linier atau lebih baik, saya memilih yang belakangan dan menghindari yang pertama.

@cznic yakin, biasanya jika dua algoritme memberi Anda hasil yang sama seperti yang Anda inginkan dengan kompleksitas yang lebih rendah (walaupun ini tidak selalu begitu terpotong dan kering - Python menggunakan jenis penyisipan untuk input kecil karena meskipun memiliki batas kompleksitas yang lebih buruk, ia memiliki lebih baik konstanta + runtime hingga titik tertentu).

Dalam hal ini (algoritme berbasis MVS vs. SAT), hasilnya berbeda sesuai tujuan dan memiliki konsekuensi yang luas. Saya menyarankan bahwa karena ini Anda tidak bisa hanya membandingkan kompleksitas algoritmik, Anda perlu mempertimbangkan dampaknya yang lebih luas.

Sepertinya masalah #25483 tidak terkait dengan vgo

Baris pertama dalam masalah itu adalah tautan ke komentar Brad dalam masalah ini: https://github.com/golang/go/issues/24301#issuecomment -390788506 . Meskipun alat ini akan berguna di luar vgo, sepertinya alat ini sebagian besar sedang dipertimbangkan untuk mengurangi beberapa kelemahan MVS (menurut pendapat/pemahaman saya).

Astaga, banyak sekali komentarnya. Saya akan mencoba menambahkan beberapa detail dan riwayat untuk membantu.

Beberapa tahun yang lalu ada sejumlah solusi manajemen ketergantungan yang berbeda (misalnya, godep, glide, dll). Untuk mengetahui jalan ke depan, beberapa hal terjadi:

1. Sekelompok orang yang berinvestasi dan berpengetahuan berkumpul dalam sebuah komite . Perhatikan, anggota tim go di Google adalah bagian dari grup ini.
2. Kelompok orang kedua yang telah menulis manajer ketergantungan atau memiliki informasi tentang mereka mendukung kelompok pertama ini.
3. Survei komunitas tentang kebutuhan dan pemikiran tentang alat yang ada (di Go dan di luar Go) dilakukan . Catatan, beberapa hasil bersifat pribadi untuk mata panitia saja.
4. Perusahaan yang menggunakan Go untuk produksi diwawancarai untuk mendapatkan detail tentang kebutuhan mereka. Rincian ini tidak umum sehingga orang dapat berbicara dengan bebas.

Data survei dan wawancara semuanya dimasukkan kembali ke dalam komite. Setelah melihat data dan memperdebatkannya, mereka memutuskan bahwa kami membutuhkan solusi dengan fitur tertentu dan membuat spesifikasi . Setelah itu pengembangan di dep mulai memenuhi kebutuhan tersebut.

Di Gophercon tahun lalu ada kontributor puncak yang mencakup orang-orang yang berinvestasi dalam manajemen ketergantungan membicarakannya. Menjelang akhir percakapan itu Russ datang ke meja dan mengatakan sesuatu seperti, saya bisa melakukan lebih baik jika saya pergi sendiri dan membangun sesuatu. Dia melakukan itu dan datang dengan vgo. Itu dilakukan secara terpisah dari masyarakat.

Apakah vgo memenuhi kebutuhan orang-orang yang diungkapkan dalam survei dan wawancara? Dari apa yang saya kumpulkan dari Russ, dia tidak membaca hasil tetapi dia mengkritik prosesnya. Mungkin ada baiknya seseorang melakukan pemetaan.

Oh, di puncak Russ memang berbagi salah satu alasan, saat itu, dia tidak suka pemecah SAT. Dia menginginkan solusi dengan baris kode yang lebih sedikit karena dia tidak ingin Tim Go di Google terlibat dalam pemeliharaan kode sebanyak itu. Saya ingat itu secara khusus karena saya melakukan beberapa perbandingan LOC antara dep, glide, dan alat lain setelah itu untuk mendapatkan gambaran perbedaan yang lebih baik.

Go adalah proyek yang dimiliki dan dijalankan oleh Google. Jika masalahnya adalah salah satu sumber daya, haruskah Go berada di bawah yayasan dan orang-orang dari organisasi lain terlibat dalam kepemilikannya? Itu cara lain untuk menambahkan sumber daya untuk mempertahankan rantai alat.

Tidak, #25483 tidak terkait dengan vgo. Saya baru saja mendaftarkannya begitu saja sebagai hal lain yang dapat dilakukan oleh perintah helper go release hipotetis. Tapi itu akan berguna setiap saat.

Maksud saya yang lebih besar adalah bahwa Go tidak pernah membuatnya sangat mudah untuk melakukan rilis paket-paket Go. Dalam kehidupan sebelumnya saya menulis http://search.cpan.org/dist/ShipIt/ untuk mengotomatisasi rilis paket Perl CPAN dan itu membuat perbedaan besar ketika Anda memiliki perkakas di sekitar hal-hal seperti itu dibandingkan melakukannya dengan tangan.

Saya hanya menyebutkan go release hipotetis sama sekali karena saya ditanya apa yang mungkin dilakukan Go secara berbeda untuk membantu manusia agar tidak membuat kesalahan.

Satu masalah aktual yang saya lihat dengan vgo tampaknya sepele untuk diperbaiki.... masalah versi maks. Jika satu perpustakaan rusak dengan v1.7 dari dep, tidak ada cara untuk menentukan itu selain dari pengecualian... yang hanya membantu sampai v1.8 keluar, yang kemungkinan masih rusak dengan cara yang sama persis.

Tampaknya sepele untuk menambahkan versi maksimal ke vgo hanya sebagai cara untuk membantu vgo menentukan kapan dua perpustakaan tidak kompatibel. Jika satu perpustakaan mengatakan perlu setidaknya v1.7 dan satu perpustakaan mengatakan perlu

Tanpa ini, vgo hanya akan menggunakan 1.7, dan salah satu perpustakaan akan rusak. Jika Anda beruntung, ada kesalahan kompiler .. kemungkinan besar hanya ada bug perilaku halus yang mungkin tidak diperhatikan sampai di jalan. Dan yang berbahaya adalah bahwa itu mungkin ketergantungan transitif yang bahkan tidak Anda hubungi secara langsung.

@natefinch batasan versi maks mendorong MVS keluar dari wilayah pemecah SMT yang sangat pintar.

Saya pikir @natefinch berarti versi maksimal sebagai pemeriksaan/filter terakhir. Setelah MVS melakukan tugasnya, vgo akan error jika salah satu batasan versi maksimal ini tidak terpenuhi. Itu masih tidak membawa kita ke wilayah pemecah SAT.

Tepat. Tidak ada pemecahan. Hanya ada "vgo mengatakan 1.7 adalah hal yang benar untuk digunakan, tetapi modul X menyatakan itu tidak berfungsi dengan versi itu". Ini sudah sesuatu yang dapat terjadi hari ini dengan vgo jika Anda memiliki sesuatu yang mengatakan require foo 1.7 dan sesuatu yang lain mengatakan exclude foo 1.7 , jika tidak ada versi foo yang lebih tinggi.

Dan kemudian apa yang harus Anda lakukan?

Anda menggunakan otak manusia untuk mencari solusi, karena tidak ada solusi mekanis. Anda mencoba menggunakan dua pustaka yang menyatakan dengan pasti bahwa mereka memerlukan versi pustaka yang tidak kompatibel. A akan pecah dengan 1,6, B akan pecah dengan 1,7. Tamat.

Anda perlu meyakinkan pembuat ketergantungan untuk memperbaiki bug (jika itu bug), meyakinkan salah satu penulis perpustakaan untuk merilis versi baru yang kompatibel dengan versi ketergantungan baru, atau melakukan banyak hal dan memperbaikinya sendiri .

Tidak ada jawaban yang bagus. Tetapi tidak ada alat di dunia yang dapat memperbaikinya untuk Anda juga.

@sdboyer

Masalahnya adalah, dan selalu, bahwa MVS hanya memecahkan masalah ilusi (menghindari SAT),

Saya tidak dapat berbicara dalam percakapan pribadi Anda dengan Russ, tetapi "menghindari SAT" tampaknya seperti argumen yang tidak berguna bagi saya. "Menghindari SAT" tidak lebih merupakan tujuan daripada "menggunakan SAT": keduanya tidak memiliki dampak nyata pada pengguna.

Seperti yang saya lihat, masalah konkret yang dipecahkan MVS adalah:

• membuat build dapat direproduksi secara default,
• membangun sedekat mungkin dengan versi yang diuji, dan
• menghindari penolakan palsu.

Kami mencapai ekosistem yang lebih baik dengan membuat alat yang membantu kami menggunakan token terbatas kami untuk kolaborasi yang bermanfaat - bukan dengan membuat alat rapuh yang menghukum kami karena berpartisipasi sejak awal.

Saya setuju. Tetapi saya ingin melihat lebih dekat pada asumsi Anda: alat mana yang "menghukum" partisipasi dan mengapa?

Salah satu contoh yang Anda berikan dalam posting Anda adalah, “Proyek kami bergantung pada [email protected] saat ini, tetapi tidak bekerja dengan [email protected] atau yang lebih baru. Kami ingin menjadi warga negara yang baik dan beradaptasi, tetapi kami tidak memiliki bandwidth saat ini.”

Asumsi (implisit) pertama yang Anda buat adalah bahwa Anda (atau pengguna Anda) memiliki waktu dan bandwidth untuk menguji proyek Anda secara mendalam terhadap semua rilis dependensinya.¹ Untuk beberapa proyek, asumsi itu sendiri mungkin tidak berlaku : dengan menetapkan harapan bahwa setiap orang menandai batas atas ketika mereka menemukan ketidaksesuaian, Anda akhirnya "menghukum" pengelola yang tidak memiliki bandwidth untuk menguji regresi dan memperbarui batas pada kemungkinan semua rilis mereka.

Sebaliknya, di bawah MVS, pengelola hanya berkewajiban untuk mendeklarasikan satu hal: "Kami menguji secara menyeluruh terhadap [email protected] dan berhasil." Jika pengguna Anda tidak melakukan apa pun untuk mengganggu itu, mereka membangun dari [email protected] dan semuanya terus bekerja seperti sebelumnya.

Di bawah MVS, _breakage hanya terjadi pada saat peningkatan eksplisit._ Itu manfaat yang signifikan: jika pengguna Anda meningkatkan beberapa ketergantungan lain sehingga menarik [email protected] dan menghentikan penggunaan paket Anda, maka mereka dapat dengan mudah mundurkan pemutakhiran itu hingga Anda punya waktu untuk memperbaikinya, _atau hingga pengelola X punya waktu untuk memperbaiki ketidakcocokan._ Dan dengan harapan yang tepat, yang terakhir mungkin jauh lebih mungkin daripada yang pertama: notch out [email protected] mungkin menjadi pekerjaan sibuk yang tidak perlu jika [email protected] mengembalikan kompatibilitas.

Asumsi kedua yang Anda buat adalah bahwa setiap ketidakcocokan yang memengaruhi _setiap bagian_ modul Anda memengaruhi _semua pengguna_ modul Anda. Jika bagian dari paket Anda yang rusak di bawah [email protected] adalah fungsi yang jarang digunakan, mengapa menahan pengguna Anda untuk meningkatkan X dalam program mereka yang bahkan tidak memanggilnya?

Anda dapat berargumen bahwa jika beberapa bagian dari modul tidak bergantung pada bagian lain, mereka harus menjadi modul yang terpisah, tetapi hal itu sekali lagi memaksa pekerjaan ekstra ke pengelola paket: jika saya hanya memiliki bandwidth untuk menguji dan memutakhirkan secara berkala, saya mungkin hanya memiliki bandwidth untuk mempertahankan satu modul, bukan seluruh kompleks modul berbutir halus dengan dependensi berbutir halus.

Secara umum, mendeteksi ketidaksesuaian dengan dependensi mengharuskan Anda untuk menguji terhadap _produk silang dari semua rilis_ dari dependensi tersebut: mungkin saja penggunaan khusus Anda atas [email protected] baik-baik saja, tetapi rusak dalam kombinasi dengan beberapa paket lain yang Anda andalkan pada. Misalnya, mungkin Anda dan ketergantungan Anda memerlukan opsi yang tidak kompatibel dalam konfigurasi global.

mereka dapat dengan mudah membatalkan peningkatan itu

Itu mengasumsikan ini adalah kesalahan kompiler atau sesuatu yang serupa sangat terlihat. Ini jauh lebih mungkin menjadi bug perilaku halus yang tidak segera terlihat. Anda memperbarui, menjalankan pengujian, dan semuanya terlihat bagus. Mungkin batas waktu yang tadinya 10 detik sekarang menjadi 30, dan itu membuang batas waktu di sisa tumpukan Anda saat sedang dimuat. Anda tidak akan menyadarinya sampai berjalan dalam produksi (sesuatu yang serupa terjadi pada kami dengan perubahan mgo beberapa tahun yang lalu).

Jika bagian dari paket Anda yang rusak di bawah [email protected] adalah fungsi yang jarang digunakan, mengapa menahan pengguna Anda untuk meningkatkan X dalam program mereka yang bahkan tidak memanggilnya?

Karena mereka mungkin tidak akan tahu apakah mereka menggunakan atau tidak menggunakan fungsi itu jika itu adalah ketergantungan transitif, dan siapa yang mengatakan bahwa beberapa jalur kode yang tidak digunakan tidak akan tiba-tiba diaktifkan saat Anda mengubah kode Anda? Jadi fungsi yang rusak itu sekarang dipanggil. Jauh lebih baik untuk mempercayai pengelola perpustakaan yang ahli dalam memahami perpustakaan mereka sendiri, bahwa jika mereka mengatakan itu tidak bekerja dengan 1.7, jangan membangun dengan 1.7.

Itu mengasumsikan ini adalah kesalahan kompiler atau sesuatu yang serupa sangat terlihat. Ini jauh lebih mungkin menjadi bug perilaku halus yang tidak segera terlihat.

Ada bug halus yang mengintai di hampir setiap versi dari hampir setiap paket perangkat lunak. Kami biasanya tidak menandai rilis sebagai benar-benar tidak dapat digunakan hanya karena kami telah menemukan satu bug seperti itu; sebagai gantinya, kami memperbaikinya di rilis poin selanjutnya.

Apa yang membuat kelas bug khusus ini istimewa?

siapa bilang beberapa codepath yang tidak digunakan tidak akan tiba-tiba diaktifkan saat Anda mengubah kode Anda?

Itulah tepatnya argumen MVS: jika Anda mengubah kode, maka Anda mendeteksi kerusakan _pada revisi itu,_ dan Anda juga dapat memperbarui batasan versi pada revisi itu.

Itu menyiratkan bahwa, sebagai pengguna, lebih mudah untuk membagi dua kegagalan jika Anda memutakhirkan dependensi Anda satu per satu daripada secara massal, tetapi itu berlaku untuk perubahan secara umum: semakin kecil perubahan Anda, semakin tepat Anda bisa bagilah mereka, terlepas dari apakah itu perubahan pada kode Anda atau dependensinya.

Apa yang membuat kelas bug khusus ini istimewa?

Ini bukan hanya bug. Ini lebih besar dari itu. Penulis perpustakaan, yang merupakan pakar terkemuka dalam kode mereka, telah memberi tahu dunia "yo, versi 1.7 dari X merusak barang-barang saya dengan cara yang sangat buruk, jangan dibuat dengan itu".

Jelas, kecuali itu adalah kesalahan kompiler, itu adalah panggilan penilaian. Jika 99 fungsi Anda panik, tetapi satu tidak... apakah itu hanya bug? Atau apakah itu ketidakcocokan total? Bagaimana jika hanya satu fungsi yang membuat panik?

Pada titik tertentu, manusia harus membuat keputusan itu. Saya lebih suka berurusan dengan ketidakcocokan yang dinyatakan secara pre-emptive yang terjadi pada waktu pembuatan, daripada khawatir tentang masalah besar yang tidak dideklarasikan yang membuatnya menjadi produksi.

Ini bukan hanya bug. Ini lebih besar dari itu. Penulis perpustakaan, yang merupakan pakar terkemuka dalam kode mereka, telah memberi tahu dunia "yo, versi 1.7 dari X merusak barang-barang saya dengan cara yang sangat buruk, jangan dibuat dengan itu".

Ada cara lain bagi penulis pustaka untuk mengungkapkan hal ini: Tulis tes yang gagal saat digunakan dengan versi X yang tidak kompatibel. Ini akan memiliki keuntungan karena tidak memerlukan perubahan pada pustaka jika X merilis versi tetap, serta menangkap apa pun regresi masa depan.

Tulis tes yang gagal saat digunakan dengan versi X yang tidak kompatibel.

Ya, saya memikirkan itu. Tetapi kemudian Anda meminta setiap biner tingkat atas untuk menjalankan semua pengujian untuk semua dependensi transitif, pengujian yang mungkin memerlukan infrastruktur yang tidak Anda miliki. Tidak semua suite uji 100% terisolasi.

Ada alasan mengapa go test ./... tidak menjalankan tes di direktori vendor.

Untuk meringkas (kemungkinan buruk) sepertinya argumen teknis utama terhadap vgo adalah bahwa perlu ada cara bagi perpustakaan untuk mendeklarasikan batasan yang dihormati secara global pada dependensi mereka sendiri.

Mengapa tidak kedua belah pihak setuju untuk menyetujui proposal yang bersaing yang mengeksplorasi bagaimana GPS2 dapat cocok dengan bagian-bagian vgo yang disukai kedua belah pihak. Kemudian, gabungkan eksperimen vgo sementara itu dan kunjungi kembali proposal GPS2 sebelum vgo menggabungkan arus utama?

Sebagai seseorang yang berjuang dengan banyak alat ketergantungan di masa lalu, saya senang dengan vgo. FWIW, sebagai anggota "komunitas", saya merasa terwakili dengan baik oleh solusi vgo sejauh ini. Namun, saya tetap terbuka untuk mempertimbangkan argumen yang mendukung penambahan batasan versi global dan berharap argumen itu berkembang lebih lanjut.

Hanya membuang ini di luar sana:

Itu mengasumsikan ini adalah kesalahan kompiler atau sesuatu yang serupa sangat terlihat. Ini jauh lebih mungkin menjadi bug perilaku halus yang tidak segera terlihat. Anda memperbarui, menjalankan pengujian, dan semuanya terlihat bagus. Mungkin batas waktu yang tadinya 10 detik sekarang menjadi 30, dan itu membuang batas waktu di sisa tumpukan Anda saat sedang dimuat.

Ini adalah masalah dalam perangkat lunak secara umum. NPM (alat pembuatan versi lain yang paling saya kenal secara pribadi) menggunakan pemecah SAT yang dikombinasikan dengan komunitas yang sangat menganut semver, dan masalah ini masih ada.

Sejauh diskusi ketergantungan transitif, kenyataannya tidak ada tongkat ajaib: di beberapa titik pengembang harus menyadari dependensi yang mereka gunakan dan meluangkan waktu untuk menguji kode dengan benar yang pada akhirnya menjadi tanggung jawab mereka. Majikan saya tidak bisa menjadi satu-satunya di mana kami diharuskan untuk membenarkan setiap perpustakaan yang kami gunakan, termasuk perpustakaan transitif, karena alasan hukum dan lainnya.

Sejujurnya, di mata saya, banyak keluhan terhadap vgo tampaknya "tidak sempurna, oleh karena itu tidak akan berhasil". Mari kita tidak gagal untuk menerapkan solusi yang baik karena menginginkan solusi yang sempurna.

Bagi saya, tampaknya sangat selaras dengan filosofi Go keseluruhan untuk tim inti untuk menyediakan alat yang bagus di sebagian besar situasi, menyerahkannya kepada komunitas untuk menyediakan alat yang lebih maju dan/atau spesifik.

@malexdev Mungkin ada masalah dengan aktor Anda dalam argumen bahwa:

Jangan sampai kita gagal menerapkan solusi yang baik karena menginginkan solusi yang sempurna.

dep adalah solusi yang baik hari ini. Salah satu yang diciptakan oleh masyarakat bekerja sama. vgo, seperti yang dimulai sebelumnya, membuat beberapa asumsi:

1. Bahwa tidak ada yang akan pernah putus dari semver, bahkan secara tidak sengaja
2. Bahwa kita perlu mengerjakan ulang basis kode yang ada di ekosistem yang ada

vgo lebih didasarkan pada "solusi sempurna" di "dunia sempurna" sementara dep bekerja hari ini mengikuti apa yang sudah berfungsi di ekosistem bahasa pemrograman lain sambil toleran terhadap kesalahan.

Anda dapat melihat ini dalam sejarah ruang masalah manajemen paket yang baru saja saya tulis .

Untuk meringkas (kemungkinan buruk) sepertinya argumen teknis utama terhadap vgo adalah bahwa perlu ada cara bagi perpustakaan untuk mendeklarasikan batasan yang dihormati secara global pada dependensi mereka sendiri.

Saya setuju dengan ringkasan ini.

Mengapa tidak kedua belah pihak setuju untuk menyetujui proposal yang bersaing yang mengeksplorasi bagaimana GPS2 dapat cocok dengan bagian-bagian vgo yang disukai kedua belah pihak.

Pada titik ini, saya tetap tidak yakin bahwa GPS2 adalah kebutuhan atau bahkan ide yang bagus. Kemampuan yang Anda sebutkan di atas dapat dipasang ke vgo di atas MVS (seperti this atau this ). Secara pribadi, saya berharap posting blog @sdboyer berikutnya akan berisi argumen yang baik terhadap MVS itu sendiri, tetapi saat ini, saya tidak benar-benar melihat alasan untuk algoritma yang berbeda - terutama yang akan menghabiskan keuntungan UX yang signifikan dari vgo.

Padahal, sejujurnya, saya juga tidak melihat alasan untuk tidak bereksperimen dengan itu.

dep adalah solusi yang baik hari ini.

Saya tidak yakin saya setuju. Saya belum pernah menggunakannya sendiri, tetapi ada kelonggaran di mana beberapa orang mengeluh tentang masalah yang tampaknya dapat dilacak secara langsung ke pendekatan pemecahan SAT-nya. Dan saya tahu bahwa saya sangat tidak senang dengan desain keseluruhan deps (mengesampingkan pertanyaan tentang pemecah ketergantungan itu sendiri, jadi alur kerja umum dan UX).

1. Bahwa tidak ada yang akan pernah putus dari semver, bahkan secara tidak sengaja

Saya minta maaf, tetapi saya telah berulang kali meminta pembenaran atas pernyataan ini dan tidak mendapatkan apa pun. Mengapa vgo menganggap ini dengan cara apa pun, bentuk atau bentuk lebih dari dep? Saya pada dasarnya tidak setuju dengan pernyataan ini. Ini adalah asumsi yang dibuat untuk menjelaskan algoritma. Sama seperti jika Anda menjelaskan algoritme dep, Anda akan menjelaskan asumsi yang dibangun ke dalam versi semantik. Paling buruk, mereka menunjukkan kerusakan yang sama jika Anda gagal mematuhi semantik itu.

Saya pikir secara umum masuk akal untuk membedakan antara bagian yang berbeda dari apa yang kita bicarakan. Beberapa keluhan tentang SIV, beberapa MVS dan beberapa vgo-shell umum. Misalnya, benar bahwa MVS tidak dapat menangani batas versi atas, tetapi itu tidak berarti bahwa vgo tidak dapat menangani batas versi atas. SIV memerlukan banyak perubahan kode di luar sana (dengan menulis ulang pernyataan impor), tetapi sekali lagi, itu bahkan tidak berarti vgo akan mengharuskannya. Meskipun untuk lebih jelasnya, saya juga tidak berpikir itu masalah besar, selama kita bisa bermigrasi. AFAICT mana yang kita bisa.

Saya baru saja menonton keynote pembuka GopherConSG @rsc tentang pembuatan versi. Dia membahas skenario di mana ketergantungan memperkenalkan perubahan yang melanggar, dan membandingkan bagaimana vgo dan dep akan menanganinya, yang tampaknya menjadi perhatian utama di sini. (Ini jam tangan yang bagus.)

Jika saya memahami maksudnya dengan benar, dep dapat merusak build juga jika batasan versi maksimum digunakan untuk menghindari versi yang buruk . Saya akan sangat tertarik untuk melihat poin ini ditanggapi oleh orang-orang di sini yang khawatir bahwa vgo kurang dalam hal ini.

@willfaught Bagi kami, dep melanggar build ketika batasan versi maksimum digunakan untuk menghindari versi yang buruk dianggap sukses! Inilah yang kita inginkan terjadi. Russ dengan benar mencatat bahwa masalah ini tidak diselesaikan secara otomatis. Batasan pada Helm>2.0.0 tidak akan memutakhirkan pengguna secara otomatis ke " [email protected] " tetapi akan berhasil (menurunkan versi grpc atau memicu kegagalan build jika itu tidak mungkin) jika pengguna secara eksplisit bergantung pada "Helm == 2.1.4". Secara pribadi, hal pertama yang biasanya saya coba ketika menghadapi masalah dengan perpustakaan adalah memaksa pembaruan ke versi terbaru. Dengan Dep, ini akan memberi tahu saya tentang kegagalan yang diperkenalkan oleh GRPC 1.4.0. Dengan vgo , satu-satunya cara Helm untuk menyampaikan ini kepada saya adalah melalui dokumentasi.

Untuk mengulangi poin ini karena terus tidak dipahami: baik dep maupun vgo tidak dapat mencegah masalah ini terjadi atau memberikan solusi yang sangat mudah. Sebaliknya, dep memungkinkan Helm untuk mengomunikasikan bahwa masalahnya ada, sedangkan vgo tidak.

Untuk meringkas (kemungkinan buruk) sepertinya argumen teknis utama terhadap vgo adalah bahwa perlu ada cara bagi perpustakaan untuk mendeklarasikan batasan yang dihormati secara global pada dependensi mereka sendiri.

Saya akan menambahkan beberapa warna pada ringkasan ini karena batasan ini diperlukan untuk menangani jalur yang tidak menyenangkan ketika aturan kompatibilitas dilanggar. vgo menetapkan aturan kompatibilitas impor dan kemudian melanjutkan untuk mengembangkan solusi dengan asumsi bahwa aturan selalu diikuti. Di dunia yang diidealkan ini, kebutuhan akan batas atas terbatas atau bahkan tidak ada sama sekali. Di dunia nyata, ini tidak akan terjadi: pengembang akan merilis pembaruan yang merusak kompatibilitas, baik secara sengaja atau tidak.

Saya pikir @Merovius adalah solusi yang bisa diterapkan. MVS akan melanjutkan seperti yang ditentukan, kemudian setelah resolusi selesai, vgo akan memeriksa setiap paket yang diselesaikan untuk pengecualian. Jika ada yang ditemukan, ini dilaporkan ke pengguna akhir, yang dapat memilih untuk mengubah dependensi mereka untuk memenuhi batasan ini atau memilih untuk menimpa dan mengabaikan batasan. Saya juga berada di sisi sebaliknya dan terkadang Anda lebih tahu daripada pengelolanya; ini berfungsi untuk aplikasi Anda dan hanya itu yang Anda pedulikan.

Ini memulihkan jalur perpustakaan perantara untuk mengomunikasikan ketidakcocokan kepada pengguna akhir. Untuk mengulangi contoh helm lagi:

[email protected] : Helm @2.1.2
[email protected] : GRPC @1.3.5

==> Pengguna meningkatkan ke [email protected] dengan sengaja.

Pengguna: Helm @2.1.3, [email protected] ("Helm diperbarui, jadi saya akhirnya bisa menggunakan grpc 1.4!")
Helm: GRPC @1.4.0

==> Bug terdeteksi! Pengguna melihat beberapa masalah dengan Helm, jadi periksa versi baru.

Pengguna: [email protected] , [email protected]
Helm: GRPC @1.3.5, GRPC lemah <1.4.0

Pengguna melihat peringatan bahwa GRPC 1.4.0 ditolak oleh pemasangan [email protected]. Karena Helm rusak untuk saya dan itulah yang saya coba perbaiki, saya menghapus ketergantungan saya pada GRPC 1.4.0 (sayangnya kehilangan beberapa fungsi yang berguna) dan menjalankan kembali MVS. Kali ini, MVS menyelesaikan GRPC ke 1.3.5 dan Helm ke 2.1.4, memeriksa ulang semua kendala yang lemah, menemukan bahwa mereka memegang, dan saya selesai.

Saya tidak mengharapkan alat apa pun untuk menyelesaikan masalah ini secara ajaib, tetapi saya mengharapkan beberapa jalan lain sebagai perpustakaan middleware. Sejauh yang saya tahu, satu-satunya pilihan dalam vgo adalah melakukan fork dan mengganti nama semua dependensi upstream saya (atau yang setara, menyalinnya ke proyek saya) jika saya ingin melindungi pengguna saya dari masalah kompatibilitas dengan dependensi ini. Saya rasa tidak ada yang menginginkan itu.

@willfaught Bagi kami, dep melanggar build ketika batasan versi maksimum digunakan untuk menghindari versi yang buruk dianggap sukses! Inilah yang kita inginkan terjadi.

Poin yang dibuat dalam pembicaraan adalah bahwa vgo tidak lebih buruk dari dep dalam skenario ini. Dalam contohnya , build tidak rusak dalam arti bahwa dep tidak dapat menemukan solusi; itu rusak dalam arti bahwa dep memang menemukan solusi, dan solusi itu menyertakan versi buruk, menghasilkan situasi buruk yang sama yang ingin kami hindari.

Anda benar-benar harus melihat videonya, yang memberikan contoh yang sangat baik, tetapi inilah intinya seperti yang saya pahami/ingat:

• Versi paket (termasuk persyaratan ketergantungannya) tidak dapat diubah
• Untuk menambahkan batasan versi maksimum ke dependensi yang ada untuk paket Anda, Anda harus menerbitkan versi baru dari paket Anda.
• Ada kemungkinan bahwa dep akan memilih versi sebelumnya dari paket Anda untuk memenuhi semua persyaratan, dalam hal ini batasan versi maksimum baru Anda tidak akan ada. Ini memungkinkan versi buruk untuk digunakan.

Saya sebagian besar setuju dengan proposal untuk menambahkan pengecualian versi maksimum, tetapi saya memiliki kekhawatiran ini: Misalkan saya meletakkan di perpustakaan saya "gunakan gRPC >1.4, <1.8" lalu di gRPC 1.9, penulis memutuskan, "Anda tahu, Helm itu benar, kami membuat perubahan besar di 1.8, kami kembali ke perilaku kami sebelumnya di 1.9.0." Sekarang orang yang mencoba mengimpor Helm+gRPC tidak akan dapat menggunakan 1.9 sampai Helm merilis versi yang mengatakan "gunakan gRPC >1.4, kecuali 1.8.0, 1.8.1, 1.8.2, tapi 1.9+ keren".

Dengan kata lain, mungkin exclude grpc 1.8 sudah cukup karena kita tidak akan tahu apakah gRPC 1.9 akan tidak kompatibel atau tidak sampai diterbitkan, di mana Helm dapat menambahkannya ke daftar pengecualian atau tidak.

Saya pada dasarnya tidak tahu apa-apa tentang ruang ini. Tetapi dari membaca diskusi di sini, sepertinya ketidaksepakatan terbesar bermuara pada bagaimana mendeteksi kasus yang salah. Artinya, baik MVS (vgo) dan SAT (dep) menangani situasi normal kurang lebih dengan baik, mungkin tidak identik, tetapi cukup baik.

SAT menyediakan kemampuan yang tidak dimiliki MVS: menggunakan SAT, pembuat paket pustaka P1 dapat mendeklarasikan "P1 memerlukan P2, dan bekerja dengan P2Version > 1.1 dan P2Version < 1.4". MVS hanya dapat mendeklarasikan "P1 memerlukan P2, dan berfungsi dengan P2Version > 1.1", dan tidak dapat menyatakan batasan "P2Version < 1.4". Dalam kasus normal, ini tidak masalah. Itu hanya penting jika beberapa operasi mencoba memutakhirkan P2 ke versi 1.4. Dalam hal ini, SAT akan melaporkan kesalahan, sedangkan MVS tidak. Saat menggunakan MVS, jika ketidakcocokan bukan kesalahan kompilasi, itu dapat menyebabkan kegagalan lama setelah fakta.

Tidak diragukan lagi para pendukung SAT melihat masalah besar lainnya dengan MVS, tetapi sejauh ini yang saya pahami.

Saya pikir perlu dicatat bahwa jika ekspresi pembatasan itu sendiri berversi--jika mereka adalah bagian dari rilis khusus P1--maka dalam rangkaian peristiwa yang normal, sebelum P2 versi 1.4 dirilis, P1 versi 2.2 akan dengan senang hati mengatakan "Versi P2 > 1.1". Hanya ketika P2 versi 1.4 dirilis, penulis P1 akan melihat ketidakcocokan, dan merilis P1 versi 2.3 dengan "P2Version > 1.1 dan P2Version < 1.4". Jadi, jika Anda menggunakan P1 versi 2.2, baik SAT maupun MVS tidak akan melaporkan masalah apa pun dengan memutakhirkan P2 ke versi 1.4, meskipun akan gagal dalam beberapa cara yang mungkin tidak kentara.

Dengan kata lain, meskipun masuk akal untuk rilis P1 untuk mencantumkan versi minimum yang kompatibel dari P2, jika rilis tersebut bekerja dengan benar dengan versi terbaru dari P2, maka tidak masuk akal untuk rilis untuk mencantumkan versi maksimum yang kompatibel. . Versi maksimum yang kompatibel akan konservatif, dan oleh karena itu semakin salah ketika versi P2 yang lebih baru dan lebih baik muncul, atau jika P2 berubah dengan cara yang tidak kompatibel di masa mendatang, akan gagal menentukan persyaratan itu karena pada saat rilis tidak t ada.

Jadi jika kita ingin memiliki sistem yang mendefinisikan apa pun selain persyaratan versi minimum, maka persyaratan tersebut tidak boleh menjadi bagian dari rilis tertentu, tetapi harus menjadi bagian dari semacam metadata yang terkait dengan paket, metadata yang dapat diambil di setiap saat tanpa memperbarui paket itu sendiri. Dan itu berarti bahwa operasi "perbarui paket ini" harus terpisah dari operasi "periksa apakah versi paket saya saat ini kompatibel."

Saya akan mengklaim lebih jauh - dan ini jelas lebih lemah daripada yang di atas - bahwa jika "periksa apakah versi paket saya saat ini kompatibel" gagal, bahwa pada umumnya tidak bijaksana untuk mempercayai alat apa pun untuk menyelesaikan masalah. Jika masalah kompatibilitas tidak dapat diselesaikan dengan operasi sederhana "upgrade setiap paket yang relevan ke versi saat ini", maka itu perlu dipikirkan. Sebuah alat dapat membimbing dalam pemikiran itu, tetapi secara umum tidak dapat menggantikannya. Secara khusus, tampaknya sangat tidak bijaksana bagi sebuah alat untuk mulai menurunkan versi paket secara otomatis.

Jadi jika kita berpikir dalam hal

1. cara untuk mendefinisikan metadata paket yang menjelaskan ketidaksesuaian paket
2. berdasarkan itu, alat yang melaporkan apakah paket Anda saat ini kompatibel

maka mungkin beberapa perbedaan utama antara MVS dan SAT menjadi kurang penting.

Terima kasih telah mengatakannya dengan baik, Ian. Untuk menindaklanjutinya, setelah kami menetapkan versi dan vgo, kami benar-benar ingin memiliki godoc.org baru (mungkin dengan nama yang berbeda) yang mencatat informasi tambahan tentang paket, informasi yang dapat dilihat oleh perintah go. Dan beberapa dari informasi itu adalah ketidakcocokan berpasangan yang dapat dilaporkan oleh perintah go sebagai peringatan atau kesalahan dalam build tertentu (yaitu, melaporkan kerusakan, tidak mencoba menyembunyikannya dengan mengatasinya). Tetapi memiliki versi sama sekali di rantai alat inti adalah langkah pertama, dan itu, bersama dengan persyaratan versi minimal dan versi impor semantik, adalah apa yang telah diterima dalam masalah ini.

Kami berkomitmen untuk mendaratkan ini semulus mungkin. Itu akan membutuhkan alat tambahan, lebih banyak penjangkauan pendidikan, dan PR untuk memperbaiki masalah dalam paket yang ada. Semua itu terhalang untuk menerima proposal ini, karena tampaknya lancang untuk bergerak maju tanpa pendekatan keseluruhan yang diterima. Tapi proposal diterima, dan pekerjaan akan mulai mendarat lebih agresif sekarang setelah ketidakpastian berakhir.

Saya memiliki pemikiran yang sama tentang info eksternal untuk kompatibilitas versi... karena kompatibilitas versi harus konstan di seluruh , itu tidak perlu berada di kontrol sumber (dan pada kenyataannya berada di kontrol sumber adalah kerugian yang pasti seperti yang dinyatakan di atas). Akan lebih baik jika ada solusi yang diusulkan untuk ini, karena sepertinya itu adalah satu-satunya masalah utama dengan MVS seperti yang diusulkan.

Sungguh luar biasa melihat diskusi bergerak secara organik ke arah ini. Ini telah menjadi salah satu dorongan utama dari keprihatinan saya, dan itu membuatnya jauh lebih mudah untuk menjelaskan masalah mendasar ketika orang-orang sudah hampir mencapainya.

@ianlancetaylor , saya pikir Anda tepat dengan pengamatan ini tentang perlunya membuat perubahan pada informasi kendala pada versi yang sudah dirilis. Seperti yang ditunjukkan @rsc , layanan semacam itu adalah sesuatu yang telah kami diskusikan/saya sarankan dalam pertemuan kami. Kita bisa melakukannya dengan godoc.org, atau yang lainnya, tentu saja. Tetapi saya sebenarnya tidak berpikir itu memerlukan layanan terpisah, dan akan lebih baik tanpanya. Saya membuat referensi cepat untuk ini di bagian yang saya terbitkan pada hari Jumat (baru saja dari jangkar itu). Jika tidak ada yang lain, dalam suatu layanan, ada pertanyaan yang kemudian harus dijawab tentang deklarasi inkompatibilitas siapa yang harus muncul dalam peringatan, yang berarti menangani identitas, dan bagaimana kita melingkupi deklarasi ke situasi tertentu di depgraph. Menyimpan deklarasi di dalam file metadata berarti kita tidak perlu khawatir tentang semua itu. Tapi lebih lanjut tentang itu sebentar lagi.

Yang benar-benar penting di sini adalah poin ini, meskipun mungkin bukan seperti yang Anda maksudkan:

mungkin beberapa perbedaan utama antara MVS dan SAT menjadi kurang penting.

Saran alat meta yang melakukan pencarian ini - ya, itu pencarian SAT - sebagai solusi untuk masalah yang diidentifikasi orang. Ini persis seperti apa yang harus kita ubah ke dalam, jika MVS berjalan seperti yang dijelaskan. Dan hal pertama yang perlu diperhatikan adalah, jika kita begitu khawatir dengan ketidakcocokan ini sehingga kita membicarakan alat pencarian, maka yang sebenarnya kita katakan adalah bahwa MVS hanya menjadi langkah dalam algoritme yang lebih besar, dan manfaat grkkability langsung keluar jendela.

Kecuali itu lebih buruk dari itu, karena tidak ada alat meta yang dapat mengatasi masalah hilangnya informasi yang muncul dari pemadatan versi minimum dan saat ini bersama-sama. Hasil besar dari itu adalah cascading rollback , yang berarti bahwa benar-benar mencoba untuk memulihkan salah satu ketidaksesuaian dalam daftar ini kemungkinan besar akan berakhir dengan membuang bagian lain dari grafik ketergantungan yang tidak perlu terkait dengan masalah Anda. Dan, pengembang tidak akan dapat mengikuti strategi pembaruan yang tidak berbahaya bagi orang lain. . (Oh, dan phantom rules , tapi itu hanya efek samping MVS secara umum).

Inilah mengapa saya menegaskan bahwa MVS adalah lapisan perantara yang tidak cocok untuk membangun alat tingkat tinggi seperti ini - "tidak sesuai untuk tujuan." Jelas bahwa orang-orang percaya ketidakcocokan ini akan terjadi, jadi MVS hanya mengambil masalah yang sulit dan membuatnya lebih sulit.

Jika sebaliknya, kami menyatukan masalah "layanan ketidakcocokan" kembali ke file metadata, maka saya yakin itu mungkin , hanya menggunakan satu set sederhana deklarasi berpasangan, untuk mencapai efek yang sama. (Ini adalah konsep konsep, tetapi tampaknya semakin menyatu)

Itu akan memerlukan bahwa bagian dari MVS berubah, tetapi MVS masih dapat berjalan di atas informasi yang dikodekan di sana. Itu sebagian besar akan berguna jika ketidakcocokan benar-benar menjadi gila, dan Anda hanya ingin menghindari semuanya. Tetapi algoritme utama akan mulai dari garis dasar yang terlihat seperti MVS, kemudian beralih ke pencarian yang lebih luas (untuk lebih jelasnya, MVS itu sendiri masih harus dianggap sebagai pencarian), tanpa kemungkinan pindah ke versi lama yang absurd.

(catatan, saya akan berlibur minggu ini, jadi tidak akan merespon sampai akhir pekan depan)

@sdboyer

Saran alat meta yang melakukan pencarian ini - ya, itu pencarian SAT

Bisakah Anda lebih spesifik? Kalimat yang Anda kutip tepat setelah Ian menyarankan alat untuk melaporkan apakah versi yang dipilih kompatibel - dan sejauh pengetahuan saya, itu adalah alternatif utama yang disarankan di sini (tentu saja itulah yang saya maksud di atas). Masalah itu pasti bukan pencarian dan itu sepele dan tidak memerlukan penyelesaian SAT (itu hanya mengevaluasi formula boolean untuk serangkaian nilai tertentu, tidak mencoba menemukan nilai yang memenuhinya).

Benar, hanya melaporkan bahwa ada beberapa nilai yang diketahui tidak kompatibel dalam rumus tidak memerlukan penyelesaian SAT. Mengambil tindakan apa pun atas dasar itu, seperti untuk alat yang membantu dalam proses menemukan hasil tanpa nilai-nilai seperti itu di dalamnya.

Saya mengutip kalimat itu bukan karena saya pikir itu menunjukkan orang-orang telah menerima pencarian seperti biasa, tetapi karena jika kami percaya bahwa melaporkan kondisi seperti itu penting, maka itu karena kami yakin kemungkinan kami akan menghadapi skenario seperti itu.

masalahnya adalah, setelah masuk akal dan pentingnya menangani kasus-kasus itu ditetapkan, sepertinya orang-orang kemudian membuat lompatan yang salah bahwa "kita bisa melakukan semua hal pencarian di atas MVS, dan itu akan baik-baik saja." kita bisa, tetapi upaya seperti itu menjadi lebih sulit untuk ditangani karena kemungkinan jalur berguna yang dipotong MVS, secara desain.

Pada 28 Mei 2018 16:02:13 EDT, Axel Wagner [email protected] menulis:

@sdboyer

Saran alat meta yang melakukan pencarian ini - ya, itu a
pencarian SAT

Bisakah Anda lebih spesifik? Kalimat yang Anda kutip tepat setelah Ian
menyarankan alat untuk melaporkan apakah versi yang dipilih adalahkompatibel - dan sejauh pengetahuan saya, itu yang utama
alternatif yang disarankan di sini (tentu saja itulah yang saya maksudkan di atas).
Masalah itu pasti bukan pencarian dan itu sepele dan
tidak memerlukan penyelesaian SAT (hanya mengevaluasi rumus boolean
untuk satu set nilai tertentu, tidak mencoba untuk menemukan nilai yang memenuhinya).

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/golang/go/issues/24301#issuecomment -392595150

Saya mengutip kalimat itu bukan karena saya pikir itu menunjukkan orang-orang telah menerima pencarian seperti biasa, tetapi karena jika kami percaya bahwa melaporkan kondisi seperti itu penting, maka itu karena kami yakin kemungkinan kami akan menghadapi skenario seperti itu.

Untuk lebih jelasnya: Saran untuk memperbaiki batas atas dengan cara ini murni reaktif terhadap kekhawatiran yang diangkat dan untuk menunjukkan bahwa hal itu dapat dilakukan (untuk secara kritis mempertanyakan klaim bahwa MVS pada dasarnya tidak sesuai untuk tujuan). Tampaknya agak tidak adil untuk mengambil konsesi dan kesediaan untuk berkompromi sebagai bukti bahwa kami pikir Anda benar selama ini.

Bagi saya, klaim itu (bahwa MVS tidak layak dan pada dasarnya langkah yang tidak dapat diubah ke arah yang salah) adalah apa yang secara pribadi saya tantang dan lensa saya membaca argumen Anda. Salah satu argumen itu adalah, bahwa itu adalah fitur jika kita dapat mendeklarasikan inkompatibilitas dan membuat algoritme pemilihan versi gagal saat ditemukan. Argumen lain yang adil adalah, jika itu terjadi, alangkah baiknya jika algoritme dapat menyelesaikannya untuk kita (yang memang membutuhkan pemecah SAT).

Namun, sementara saya pikir itu adalah masalah yang valid dan adil, saya tidak percaya mereka lulus standar untuk membuktikan kepada saya bahwa MVS pada dasarnya tidak layak. Saya masih percaya MVS sebagai titik awal membawa fitur yang baik dan penting ke meja. Dan jika kekhawatiran tersebut ternyata menyebabkan rasa sakit yang signifikan dalam praktik, masih ada banyak cara yang dapat kami ulangi - mulai dari menambahkan batas atas (baik sebagai bagian dari go.mod atau sebagai layanan terpisah) dengan kegagalan murni hingga dan termasuk menambahkan pemecah SAT penuh dan mengunci file di beberapa titik. Yaitu saya setuju dengan Anda bahwa hal-hal itu akan terjadi, tetapi a) saya (mungkin naif) optimis bahwa mereka tidak akan menyebabkan banyak rasa sakit seperti yang Anda antisipasi dan b) bahwa itu adalah masalah yang dapat dipecahkan bahkan ketika kita memulai dengan MVS.

Terpikir oleh saya bahwa sesuatu di luar kontrol sumber yang menentukan kompatibilitas akan mengubah determinisme sistem MVS. Jika Anda memiliki foo >= 1.5.0 sebagai batasan dalam satu lib, dan lib lain memiliki foo >= 1.6.0. Kemudian letakkan keduanya dalam biner dan mereka memilih 1.6.0. Di MVS ini semua yang Anda butuhkan untuk membangun berulang. itu akan selalu memilih 1.6

Tetapi jika Anda menambahkan kompatibilitas eksternal ke dalam campuran, maka Anda dapat memperbarui perpustakaan pertama untuk mengatakan bahwa itu tidak kompatibel dengan 1.6, dan kemudian algoritme akan memilih 1.7, meskipun kodenya tidak berubah... Yang berarti Anda perlu file kunci lagi.

Sebagai referensi, saya tidak berpikir file kunci adalah hal yang buruk. Sangat menyenangkan memiliki daftar eksplisit tentang apa yang perlu Anda bangun. Dan itu harus membuatnya cepat. Tidak perlu logika ajaib.

@natefinch Jika file go.mod aplikasi telah diperbarui untuk memerlukan v1.7.0 karena alat kompatibilitas eksternal menunjukkan v1.6.0 tidak kompatibel, Anda tidak memerlukan file kunci. Karena menentukan v1.7.0 tinggal di file go.mod, penulis juga dapat menambahkan komentar yang mengatakan mengapa v1.7.0 digunakan dan informasi itu akan berguna bagi pembaca.

@leighmcculloch , jika ada file dalam aplikasi yang diperbarui maka itu adalah build yang berbeda dan benar-benar di luar lingkup masalah "build yang dapat direproduksi tanpa lockfile".

informasi kompatibilitas out-of-band diusulkan untuk mencerminkan bagaimana pengetahuan berkembang: tidak ada ketidaksesuaian yang diketahui pada waktu rilis, tetapi kemudian menjadi jelas dan informasi tambahan diterbitkan mengenai versi yang sudah dirilis. IMHO menurut definisi pendekatan ini mengarah pada perubahan bagaimana dependensi ditarik, jika tidak, mengapa ekstrak informasi ketidakcocokan ini sama sekali?

@redbaron @natefinch

Maksud dari informasi ketidakcocokan adalah bagi penulis perpustakaan untuk mengomunikasikan informasi ketidakcocokan kepada penggunanya. Apakah informasi itu digunakan pada saat pembuatan atau pada waktu rilis adalah pertanyaan yang berbeda.

Dalam kasus vgo, ide saat ini adalah hanya menampilkan peringatan (atau berpotensi serak). Tetapi terutama untuk tidak membiarkannya memengaruhi pilihan versi yang digunakan (karena itu akan membutuhkan penyelesaian SAT). Jadi sebenarnya tidak masalah, Anda dapat menggunakannya di salah satu atau keduanya dan itu akan memenuhi tugasnya dengan baik, sambil mempertahankan sifat pengulangan¹.

Dalam dep, informasi ini hanya digunakan pada waktu rilis dan kemudian direkam ke file kunci, yang digunakan pada waktu pembuatan. Jadi sepertinya kami sedang mempertimbangkan penggunaan waktu rilis "cukup baik", setidaknya jika menyangkut masalah vgo vs. dep.

Saya masih tidak berpikir kita harus benar-benar menjawab pertanyaan-pertanyaan itu sekarang.

[1] Secara pribadi, saya berpendapat bahwa menggunakannya pada waktu rilis dan hanya jika -v digunakan pada waktu pembuatan lebih baik, karena pengguna tidak harus memutuskan apakah peringatan dapat ditindaklanjuti atau tidak.

@rsc menulis:

Untuk menindaklanjutinya, setelah kami menetapkan versi dan vgo, kami benar-benar ingin memiliki godoc.org baru (mungkin dengan nama yang berbeda) yang mencatat informasi tambahan tentang paket, informasi yang dapat dilihat oleh perintah go. Dan beberapa dari informasi itu adalah ketidakcocokan berpasangan yang dapat dilaporkan oleh perintah go sebagai peringatan atau kesalahan dalam build tertentu (yaitu, melaporkan kerusakan, tidak mencoba menyembunyikannya dengan mengatasinya).

Saya bertanya-tanya apakah perlu untuk merekam ketidakcocokan pasangan-bijaksana. Cara saya melihatnya saat ini adalah bahwa ketidakcocokan antara modul A@vN dan modul B@vM benar-benar karena B membuat perubahan yang tidak kompatibel dari beberapa versi vL di mana L < M.

Jika modul B tidak membuat perubahan yang tidak kompatibel, maka modul A hanya memiliki bug. Jika ya, maka masalahnya adalah tentang B itu sendiri, bukan tentang pasangan A dan B.

Jadi ISTM bahwa repositori publik metadata modul mana pun hanya dapat merekam ketidakcocokan modul apa pun dengan versi sebelumnya, yang dapat membuat masalah lebih mudah ditangani. Laporan ketidakcocokan ini sangat mirip dengan laporan bug, meskipun tidak dapat diselesaikan karena setelah versi diterbitkan, itu tidak dapat diubah.

Saat Anda memutakhirkan versi modul Anda, alat go dapat mempertimbangkan metadata dan menolak untuk mempertimbangkan versi yang tidak kompatibel dengan versi yang saat ini dipilih. Saya pikir ini menghindari kebutuhan untuk menyelesaikan SAT. Itu juga dapat memutuskan bahwa modul yang diberikan memiliki terlalu banyak laporan ketidakcocokan dan menolak untuk menambahkannya sebagai ketergantungan.

Satu set tupel formulir ( module , oldVersion , newVersion , description ) mungkin cukup.

alat go dapat mempertimbangkan metadata dan menolak untuk mempertimbangkan versi yang tidak kompatibel dengan versi yang dipilih saat ini

Tentu saja, ini tidak berfungsi saat Anda menambahkan beberapa dependensi, yang di antaranya mengharuskan penggunaan versi yang saling tidak kompatibel, karena versi baru bukan bagian dari modul yang ada, tetapi mungkin tersedia heuristik yang masuk akal. Ini bukan AFAICS yang penting, karena dependensi harus ditambahkan relatif jarang.

Saya khawatir go release menjadi "kompiler yang cukup pintar" dalam diskusi ini. Apa yang sebenarnya diharapkan pengguna dari go release di Go 1.11/12? Saya pikir itu membuat perbedaan untuk apa harapan yang masuk akal di sekitar MVS/SIV.

Terima kasih atas energi yang telah Anda bawa ke Go dan khususnya proposal ini.

Tujuan pertama dari proses proposal adalah untuk "[m]memastikan bahwa proposal mendapatkan evaluasi yang tepat, adil, tepat waktu, tercatat dengan jawaban yang jelas." Proposal ini dibahas panjang lebar dan kami menerbitkan ringkasan diskusi. Setelah enam minggu dan banyak diskusi, panitia peninjau proposal - bertindak sebagai penengah karena saya yang menulis proposal - menerima proposal tersebut.

Satu masalah GitHub adalah tempat yang sulit untuk berdiskusi secara luas, karena GitHub tidak memiliki utas untuk untaian percakapan yang berbeda dan bahkan tidak menampilkan semua komentar lagi. Satu-satunya cara diskusi seperti ini berhasil adalah dengan kurasi aktif ringkasan diskusi. Bahkan ringkasannya menjadi berat pada saat proposal diterima.

Sekarang setelah proposal diterima, masalah ini bukan lagi tempat yang tepat untuk didiskusikan, dan kami tidak lagi memperbarui ringkasannya. Alih-alih, harap ajukan masalah baru yang ditargetkan tentang masalah yang Anda alami atau saran nyata untuk perubahan, sehingga kami dapat memfokuskan diskusi tentang setiap topik tertentu. Harap awali masalah baru ini dengan "x/vgo:". Jika Anda menyebutkan #24301 dalam teks terbitan baru, maka akan dirujuk silang di sini agar orang lain dapat menemukannya.

Satu poin terakhir adalah bahwa menerima proposal berarti menerima ide, bukan bug implementasi prototipe dan semuanya. Masih ada detail yang harus diperbaiki dan bug yang harus diperbaiki, dan kami akan terus melakukannya bersama.

Terima kasih sekali lagi atas semua bantuan Anda.

Masih banyak pekerjaan yang harus dilakukan (lihat label modul ) tetapi implementasi modul awal seperti yang diusulkan dalam masalah ini telah dilakukan ke pohon utama, jadi saya menutup masalah ini.