Go: cmd/go: asumsikan GOPATH=$HOME/go jika tidak disetel

/cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

Saya menyukainya, tetapi apakah kami memiliki preferensi khusus untuk "gocode" dan bukan sesuatu seperti "gopath"?

Berapa banyak orang yang sudah menggunakan GOPATH=$HOME/gocode? Sepertinya saya tidak banyak. Itu menunjukkan itu adalah default yang salah.

"gocode" akan memiliki mesin pencari dan kebingungan lainnya dengan alat populer github.com/nsf/gocode.

Apakah kita memiliki informasi tentang apa yang kebanyakan orang lakukan?

Saya menggunakan GOPATH=$HOME/gopath sendiri.

Jempol di sini jika Anda saat ini menggunakan GOPATH=$HOME

Jempol di sini jika Anda saat ini menggunakan GOPATH=$HOME/gopath

Jempol di sini jika Anda saat ini menggunakan GOPATH=$HOME/gocode

Haruskah saya melakukan polling twitter di @golang?

@campoy , kedengarannya bagus. Mungkin lebih baik daripada mengundang semua orang ke bug ini.

Bagaimana dengan $HOME/go (yang saya gunakan).

Lihat juga: http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$RUMAH: 8,9%
$HOME/pergi: 50.6%
Lainnya : 40,5%

Saya benar-benar berharap saya telah membagi lebih banyak opsi untuk yang satu ini.

Voting dimulai: https://twitter.com/golang/status/781189567437164544

Pada Rabu, 28 Sep 2016, 10:51 Edward Muller [email protected]
menulis:

Bagaimana dengan $HOME/go (yang saya gunakan).

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

Lihat juga Kolom I di sini : https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid =1525640201

@freeformz ,

$HOME/go bertentangan dengan path go source code (go.googlesource.com/go) sering diperiksa. Sangat buruk bahwa komunitas memberkati lokasi ini sebagai default untuk GOPATH :( Saya khawatir jika seseorang lupa mengatur GOPATH mereka dan menjalankan alat go, itu akan mengacaukan direktori pengembangan mereka saat ini.

@rakyll untuk masing-masing milik mereka, hanya ingin menunjukkan apa yang saya dan banyak orang lain gunakan. go.googlesource.com/go diperiksa di /usr/local/go.git di sistem saya.

Berapa banyak orang yang sudah menggunakan GOPATH=$HOME/gocode? Sepertinya saya tidak banyak. Itu menunjukkan itu adalah default yang salah.

Sebagai catatan, saya menggunakan GOPATH=$HOME , tetapi saya merasa bahwa ini akan terlalu kontroversial dan mengurangi tujuan proposal ini, yaitu untuk meningkatkan pengalaman bagi pengguna baru.

@freeformz , saya kira kita tidak perlu peduli dengan jalur kanonik yang ada di luar $HOME. Default untuk GOPATH akan berada di $HOME di suatu tempat dan persyaratan minimalnya adalah tidak bertentangan dengan jalur kritis yang ada.

$HOME/gocode terdengar asing bagi saya tetapi itu bisa menjadi pilihan yang sangat bagus.

Intinya adalah, tidak masalah apa defaultnya, hanya saja ada satu.

Tidak masalah apa defaultnya, karena menyetel default ini pada dasarnya akan membuat semua orang yang baru mengenal Go bekerja beberapa tahun dari sekarang.

Perintah go berfungsi agar tidak bingung ketika GOPATH=$GOROOT secara eksplisit; Saya yakin logika yang sama dapat dibuat untuk diterapkan pada pengaturan implisit juga. Jadi saya tidak terlalu khawatir tentang menghancurkan $HOME/go secara tidak sengaja.

Saya masih bertanya-tanya apakah alih-alih default tetap, kita harus mengendus secara otomatis orang tua direktori saat ini untuk mencari tahu di mana GOPATH berada. Inilah yang dilakukan banyak alat sumber akhir-akhir ini (misalnya, setiap sistem kontrol versi), jadi ini adalah konsep yang akan dipahami orang. Dan itu tidak memaksa mereka untuk menggunakan satu nama direktori atau hanya memiliki satu ruang kerja GOPATH. Tapi kita mungkin juga berdiskusi tentang masalah aslinya.

@rsc Saya ingin default itu menjadi GOPATH=$HOME karena itu berarti $GOPATH/bin akan berada di jalur mereka (setidaknya pada sebagian besar distribusi linux, tidak yakin tentang darwin).

$GOPATH=$HOME/go juga merupakan pilihan yang baik dan mereka yang memiliki sumber kompiler yang diperiksa di sana akan telah menetapkan GOPATH=something else sehingga tidak ada kemungkinan konflik.

Untuk lebih jelasnya, saya tidak mencoba untuk menjadi kurang ajar ketika saya mengatakan

Intinya adalah, tidak masalah apa defaultnya, hanya saja ada satu.

Alih-alih mencoba untuk menekankan tujuan proposal ini adalah agar alat go menggunakan nilai default untuk $GOPATH ketika salah satunya tidak disediakan karena ini merupakan sumber kebingungan dan frustrasi yang terus-menerus bagi begitu banyak pendatang baru dalam bahasa tersebut.

Saya sedang mengendus otomatis karena gagal dalam kasus penggunaan utama, yaitu:

1. Saya telah menginstal Go, saya sebenarnya tidak membaca dokumen instalasi Go, hanya mengikuti apa yang tertulis di README repo yang mengatakan brew install go
2. Saya telah menjalankan go get github.com/thething/theproject
3. Sekarang saya mendapatkan kesalahan tentang tidak mengatur $GOPATH. Apa itu? Saya hanya ingin menjalankan program ini yang di-tweet oleh seseorang!

Nilai default GOPATH=$HOME/go SGTM, dengan asumsi kita memutuskan pendekatan default dan bukan auto-sniffing.

Perintah go berfungsi agar tidak bingung ketika GOPATH=$GOROOT secara eksplisit; Saya yakin logika yang sama dapat dibuat untuk diterapkan pada pengaturan implisit juga.

Kedengarannya bagus.

tidak yakin tentang darwin

Bukan pada darwin.

Jika ini untuk pendatang baru, saya akan menyarankan agar tidak GOPATH=$HOME karena itu akan membuat tiga direktori di direktori home mereka versus hanya satu. Saya tidak tertarik pada perangkat lunak yang mencemari direktori rumah saya melebihi yang diperlukan.

@mvdan Saya mengerti dan reaksi Anda adalah mengapa saya tidak mengusulkan GOPATH=$HOME .

Jika _I_ secara pribadi ingin menetapkan GOPATH ke $HOME , maka opsi itu akan tetap tersedia untuk saya, dan saya tidak perlu membuat perubahan jika proposal ini diterima untuk Go 1.8.

@davecheney

default ke nilai GOPATH=$HOME/gocode

Tidak ada variabel HOME default di Windows. Apa yang Anda usulkan untuk dilakukan di Windows?

Saya ingin default itu menjadi GOPATH=$HOME karena itu berarti $GOPATH/bin akan berada di jalurnya

Saya selalu khawatir memiliki $GOPATH/bin di PATH saya. go get menginstal program orang lain di sana. Apakah kita benar-benar ingin pengguna Go baru menginstal program acak dari Internet di suatu tempat di PATH mereka?

Alex

Saya bukan pengguna windows yang berpengalaman, tetapi saya berasumsi ada beberapa gagasan tentang jalur dasar tempat dokumen dan pengaturan disimpan. Untuk tujuan diskusi ini, asumsikan bahwa saya sedang berbicara tentang jalur itu dalam konteks pengguna windows.

Jika tidak ada jalur seperti itu, asumsikan C:/gocode.

Tulis komentar saya di GOPATH=$HOME, sementara ini dan akan terus menjadi preferensi pribadi saya, saya menyadari bahwa ini adalah opsi kontroversial untuk nilai default dan karena itu tidak menyarankannya sebagai nilai yang diusulkan.

Deteksi otomatis penuh dengan bahaya. Saya mulai membuat prototipe ini beberapa waktu lalu, tetapi itu menambah kompleksitas yang signifikan baik pada alat go maupun pengalaman pengguna.

Saya tidak mengetahui apa yang terjadi dengan kelompok kerja manajemen paket, tetapi saya dapat membayangkan masa depan yang tidak terlalu jauh di mana GOPATH dihilangkan sepenuhnya.

Yang mengatakan, bahkan jika GOPATH menghilang beberapa waktu dalam waktu dekat, mungkin masih ada nilai dalam pengaturan default. Jika menurut kami GOPATH kemungkinan besar akan menghilang, tidak masalah apa yang kami atur.

Dari apa yang saya baca di atas, ada beberapa konsensus bahwa:

1. Sebagai default, GOPATH=$HOME terlalu invasif.
2. Defaultnya harus menyertakan string go suatu tempat (kemungkinan sebagai awalan).

Saya tidak khawatir tentang GOPATH menjadi tiruan dari go repo utama (yaitu, GOPATH == GOROOT). Orang yang memeriksa go repo cenderung memiliki set GOPATH. Alat go akan tetap mendeteksi konflik, seperti saat ini.

Dengan mengingat hal itu, default yang paling ringkas adalah $HOME/go , yang menurut saya cukup masuk akal.

Saya berasumsi ada beberapa gagasan tentang jalur dasar tempat dokumen dan pengaturan disimpan.

Saya tidak tahu hal seperti itu. Mungkin pengguna Windows lain akan berkomentar di sini.

Jika tidak ada jalur seperti itu, asumsikan C:/gocode.

Anda ingin C:gocode sebagai gantinya.
Menempatkan sesuatu di root C:\ kedengarannya tidak benar bagi saya. Apakah Anda merekomendasikan GOPATH untuk disetel ke /gocode di Linux?
Tetapi, mengingat bahwa penginstal Windows sudah menginstal Masuk ke C:go, C:gocode untuk GOPATH setidaknya konsisten.

Alex

Tetapi, mengingat bahwa penginstal Windows sudah menginstal Masuk ke C:go, C:gocode untuk GOPATH setidaknya konsisten.

GOPATH tidak boleh disediakan untuk setiap pengguna? Agar sama dengan UNIX, %USERPROFILE%\gocode , saya kira.

Go+ poll di https://goo.gl/xAsgEj

setelah saya menggunakan sesuatu seperti $HOME/go-programs untuk waktu yang lama, saya mengganti GOPATH ke $HOME. jadi, sekarang saya memiliki struktur berikut:

$HOME/bin
$HOME/pkg
$HOME/src/
$HOME/src/github.com/user/some_github_project
$HOME/src/some_project

struktur ini lebih umum dan juga dapat digunakan untuk digunakan dengan bahasa atau proyek lain dan dengan github. misalnya saya punya $HOME/src/talks (baca di home/sources/talks untuk file penurunan harga) atau proyek lain dalam beberapa bahasa (seperti $HOME/src/github.com/user/html) tetapi juga sumber dan saya punya satu tempat untuk banyak sumber proyek dengan atau tanpa korespondensi github.

bin atau pkg dapat dianggap berantakan tetapi saya pikir tidak terlalu mengganggu. lebih berantakan memiliki banyak folder sumber untuk orang yang menggunakan banyak bahasa.

jadi, dari sudut pandang saya, tempat GOPATH terbaik adalah $HOME.

Saya menggunakan $HOME/gocode sebagai GOPATH saya.
Saya menentang $HOME/go karena terkadang Anda tidak memiliki hak akses root dan Anda perlu menginstal Go di bawah direktori home Anda. Dalam kasus seperti itu, saya pikir $HOME/go akan menjadi yang terbaik untuk GOROOT.
Jadi kita harus menggunakan sesuatu yang berbeda dari $HOME/go sebagai GOPATH.

@hnakamur Kembali ketika saya menginstal Go secara manual (sekarang menggunakan Ubuntu Make), saya memasukkannya ke dalam $HOME/bin/go-${go_version} (dengan symlink dari $HOME/bin/go ke $HOME/bin/go-$ {version}/bin/go, jadi saya tidak perlu mengedit $PATH saya)

@tbroyer Ini ceruk. Saya kira sebagian besar pengguna tidak menginginkan konfigurasi atau pengaturan tambahan. Menurut pendapat saya, ~/bin digunakan untuk meletakkan skrip atau binari sendiri (seperti saya). Dan saya pikir ~/bin (~/src, ~/pkg) membuat bit sulit untuk menghapus binari go.

Saya menggunakan $HOME untuk GOPATH saya.
Mengapa mengatur GOPATH secara otomatis, mengapa tidak menaikkan peringatan dengan info yang bagus bagaimana mengaturnya jika GOPATH tidak ada?

Mengapa mengatur GOPATH secara otomatis, mengapa tidak menaikkan peringatan dengan info yang bagus bagaimana mengaturnya jika GOPATH tidak ada?

Masalahnya bukan karena orang tidak tahu cara menyetel variabel lingkungan (sebagian besar), tetapi meskipun Anda melakukannya, rasanya buruk harus melewati rintangan untuk mulai menggunakan Go. Mampu menggunakan Go out of the box dengan default yang waras segera setelah diinstal membuat pengalaman semulus mungkin, dan berarti lebih banyak orang cenderung benar-benar mencoba Go setelah mengunduhnya, alih-alih menabrak penghalang jalan, kehilangan momentum mereka, dan memutuskan itu tidak layak main-main.

Saya cenderung setuju dengan Chris dan Andrew: jika akan ada GOPATH default, seharusnya hanya $HOME/go, bukan gopath atau gocode. _Kebanyakan_ pengguna tidak memiliki distribusi Go yang diperiksa di sana (dan setiap orang yang melakukannya hari ini telah menyetel GOPATH, jadi ini tidak akan mengganggu mereka). Defaultnya perlu masuk akal untuk pengguna baru, bukan pengguna tingkat lanjut, dan bagi sebagian besar pengguna $HOME/go sangat masuk akal.

Jaana mengemukakan kekhawatiran tentang perintah go yang menjadi bingung jika $HOME/go kebetulan merupakan distribusi Go, tetapi perintah go sudah memeriksa GOPATH=$GOROOT yang tidak disengaja. Sangat mudah untuk memeriksa apakah itu benar ketika GOPATH juga diatur secara implisit. Sebenarnya juga akan mudah untuk menambah cek untuk mencari, katakanlah, $HOME/go/src/cmd/go/alldocs.go, untuk menghindari kebingungan bahkan ketika GOROOT!=$HOME/go tetapi $HOME/go melakukannya mengandung distribusi Go.

$HOME/go bukan pilihan yang baik untuk GOPATH. mari kita buat latihan perilaku sederhana... pengguna baru dapat dengan mudah menganggap default sebagai praktik terbaik. katakanlah saya pengguna baru, mengapa saya harus menganggap default sebagai hal yang buruk? lebih dari itu cara termudah (dan terbaik?) untuk menginstal golang adalah dengan membongkar di $HOME karena dengan metode ini kompiler selalu di versi terakhir dan tidak perlu hak root sehingga Anda dapat dengan mudah mengira bahwa banyak pengguna akan memiliki kompiler go di $HOME/pergi. mengapa saya harus memindahkan kompiler di /usr/local padahal saya tidak bisa?
lebih dari itu mereka dapat membuat proyek dan dapat mengkloning proyek di folder ini. jadi, mereka akan memiliki folder yang berantakan dan dengan sedikit ceroboh mereka dapat dengan mudah menghapus folder proyek mereka dengan instalasi ulang golang baru.
juga, pengguna windows memiliki c:go secara default.

Saya suka $HOME/gopath. Ia mengatakan apa adanya.
Hasil pertama di Google untuk "gopath" adalah halaman yang tepat.

Jika default diadopsi, dapatkah fungsi func GOPATH() string ditambahkan ke runtime ? Saat ini seseorang dapat menggunakan os.Getenv() , tetapi dengan default itu tidak akan sesederhana itu.

@btracey , GOPATH adalah daftar, bukan nilai tunggal. Gunakan filepath.SplitList . Juga, GOPATH bukan fungsi dari runtime. Ini hanya menyangkut cmd/go .

Untuk kompatibilitas mundur, kami mungkin perlu mengatur GOPATH dalam proses'
lingkungan jika tidak ada yang disetel.

Pada 30 September 2016 pukul 08:10, Brendan Tracey [email protected]
menulis:

Jika default diadopsi, dapatkah fungsi string func GOPATH() ditambahkan?
untuk menjalankan? Saat ini seseorang dapat menggunakan os.Getenv(), tetapi dengan default it
tidak akan begitu sederhana.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/17262#issuecomment -250605418, atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

Anda benar @bradfitz. Solusi yang diusulkan oleh @adg akan memenuhi semua kegunaan saya.

Ini adalah kerutan yang menarik. Saya dapat melihat ini gagal saat ini ketika tidak
GOPATH diatur, tetapi juga ketika GOPATH berisi beberapa nilai, dan kemudian
ada kasus di mana aplikasi dibangun di satu mesin dan digunakan di
lain.

Saya tidak ingin mengabaikan penggunaan GOPATH ini, saya mengerti rasa sakitnya
dapat menemukan file dukungan untuk aplikasi Anda, tetapi saya ingin
untuk memahami seberapa luas penggunaan ini, dan bagaimana arus
implementasi menangani masalah yang saya soroti di atas.

Pada Jum, 30 Sep 2016, 08:35 Brendan Tracey [email protected] menulis:

Anda benar @bradfitz https://github.com/bradfitz. Solusinya
diusulkan oleh @adg https://github.com/adg akan memenuhi semua kegunaan saya.

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

Penggunaan saya bukan yang biasa. Saya melakukan penelitian ilmiah, dan saya merasa sangat efektif untuk tidak hanya memiliki gopath/src dan gopath/bin , tetapi juga gopath/data dan gopath/results . Ini memudahkan untuk menyalin file sumber ke sistem baru tanpa juga harus menyalin (gigabyte) file hasil. Sistem baru (katakanlah sebuah cluster) menghasilkan file hasil baru, dan saya dapat menyalin hasil tersebut ke lokasi pusat. Sangat mudah untuk mengatakan gopath = os.Getenv("GOPATH") , dan menyimpan file ke sesuatu seperti filepath.Join(gopath, "results", "projectname", result.json) .

Terima kasih. Agar jelas, saya tidak bermaksud menyiratkan bahwa penggunaan Anda salah atau
salah, saya hanya ingin memahami penggunaan GOPATH wrt ini untuk
kendala yang saya soroti.

Pada Jumat, 30 Sep 2016, 09:09 Brendan Tracey [email protected] menulis:

Penggunaan saya bukan yang biasa. Saya melakukan penelitian ilmiah, dan saya telah menemukan
sangat efektif untuk tidak hanya memiliki gopath/src dan gopath/bin, tetapi juga
gopath/data dan gopath/hasil. Ini membuatnya mudah untuk menyalin sumbernya
file ke sistem baru tanpa juga harus menyalin (gigabyte)
file hasil. Sistem baru (katakanlah sebuah cluster) menghasilkan file hasil baru,
dan saya dapat menyalin hasil tersebut ke lokasi pusat. Sangat mudah untuk
lalu ucapkan gopath = os.Getenv("GOPATH"), dan simpan file ke sesuatu seperti filepath.Join(gopath,
"hasil", "nama proyek", hasil.json).

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

Jempol di sini jika Anda saat ini menggunakan GOPATH=$HOME/.go

@davecheney jangan tersinggung, hanya ingin memberikan konteks yang cukup agar bermanfaat.

Mari kita tinggalkan penggunaan GOPATH untuk mencari file dukungan dari diskusi ini.

(GOPATH dimaksudkan untuk menjadi pengaturan waktu kompilasi, bukan run-time. Saya tahu bahwa orang terkadang mengaburkan ini dan menggunakan GOPATH untuk menemukan file terkait saat run-time, tetapi saya tidak berpikir kita harus mendorong itu atau membuat lebih mudah dilakukan. Kami membutuhkan cerita yang lebih baik untuk file dukungan secara umum, tetapi itu harus menjadi masalah terpisah.)

Terkait dengan menemukan file terkait saat run-time: #12773

Maaf mencemari diskusi sekali lagi @rsc , tetapi @randall77 , #12773 lebih sulit digunakan daripada hanya mengatasi masalah ini secara langsung. Kode khusus yang memerlukan file (atau untuk menyimpan file) dapat sering berpindah-pindah, dan saya ingin tempat yang tetap untuk input/output agar tidak bergantung pada (dan terpisah dari) refactoring.

Masalah ini adalah tentang kemungkinan nilai default GOPATH. Ini _bukan_ tentang penggunaan alternatif GOPATH.

Jika target pengguna untuk perubahan ini hanya mereka yang hanya ingin
instal program baru yang ditulis dalam Go, dan bukan program yang benar-benar ingin
tulis Go, lalu bagaimana kalau kita buat go, dapatkan kloning di direktori per pengguna di
$TMPDIR, dan biarkan biner di $PWD jika $GOPATH tidak disetel? (Jelas sekali
ini hanya masuk akal untuk go get import.path/for/a/command, jika bukan a
perintah, go get harus gagal tanpa $GOPATH disetel)

Untuk orang luar, ini masuk akal, seperti wget a file.

Setelah pengguna ingin mulai menulis kode Go, mereka harus mempelajari cara menyetel
GOPATH dengan benar.

Saya menentang $HOME/go karena terkadang Anda tidak memiliki hak akses root dan Anda perlu menginstal Go di bawah direktori home Anda. Dalam kasus seperti itu, saya pikir $HOME/go akan menjadi yang terbaik untuk GOROOT.

Jika Anda menggunakan sistem Linux, saya berpendapat bahwa tempat terbaik untuk $GOROOT mungkin berada di $HOME/.local/opt/go, bukan $HOME/go, tergantung pada bagaimana Anda menafsirkan tujuan $HOME/.local , karena hanya $HOME/.local/share (tampak seperti mirror /usr/local/share) yang didefinisikan dalam spesifikasi direktori Basis XDG: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest. html.

Orang juga dapat berargumen bahwa default terbaik untuk GOPATH/GOBIN (di Linux) adalah:
GOPATH=$XDG_DATA_HOME/go, atau $HOME/.local/share/go
GOBIN=$HOME/.local/bin

Namun itu mungkin bukan yang paling mudah dipahami oleh pengguna baru? Dan itu juga akan membuat tidak jelas apa pendekatan terbaik di Windows. $HOME/go dan $USERPROFILE/go tampaknya pragmatis.

Tolong, _please_ jangan biarkan utas ini berubah menjadi diskusi tentang nama jalur Linux kanonik dan lokasi penyimpanan. Itu tidak produktif, dan saya merasa diskusi ini telah menyimpang cukup jauh dari posting awal Dave Cheney.

Saya juga tidak yakin lokasi absolut yang sebenarnya sangat penting, saya pikir semua utas ini benar-benar perlu diputuskan adalah "apakah kita menginginkan Gopath default?" (kedengarannya seperti itu kurang lebihnya ya) dan "haruskah itu dibagikan ke seluruh sistem, atau lokal ke pengguna" (sejauh ini sebagian besar diskusi adalah tentang lokal). Setelah itu, siapa pun yang menerapkan dapat memilih $HOME/gocode atau $HOME/go atau /usr/share/go/ atau apa pun yang mereka inginkan yang tampaknya masuk akal bagi siapa pun yang meninjau PR, dan semuanya mungkin akan tetap baik-baik saja.

Saya pikir GOPATH di seluruh sistem adalah non-starter karena masalah izin.

kami

Jalur lebar sistem adalah, baik atau buruk, GOROOT, yang distro
seperti yang digunakan debian untuk menginstal paket "lebar sistem", untuk lebih baik atau untuk
lebih buruk.

GOPATH di seluruh sistem berada di luar cakupan proposal ini, proposal ini
merekomendasikan jalur yang diturunkan dari nilai pengguna yang masuk.

Pada Selasa, 4 Okt 2016, 08:52 Andrew Gerrand [email protected] menulis:

Saya pikir GOPATH di seluruh sistem adalah non-starter karena masalah izin.

kami

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

Tolong, tolong jangan biarkan utas ini berubah menjadi diskusi tentang nama jalur Linux kanonik dan lokasi penyimpanan. Itu tidak produktif

Baiklah, jangan. Poin utama saya adalah benar-benar untuk menunjukkan alasan lain bahwa $HOME/go mungkin tidak bermasalah sebagai default GOPATH, karena itu mungkin bukan jalur "Linux idiomatik" yang paling untuk instalasi pengguna lokal Go (alias GOROOT).

Selain itu, saya yakin telah dibahas sebelumnya untuk menggunakan XDG_CACHE_HOME untuk GOPATH default, itulah sebabnya saya menyebutkan XDG_DATA_HOME -- meskipun saya tidak tahu peran apa yang dilayani oleh penulis dokumen tertaut, atau seberapa "resmi" itu .

$RUMAH/kerja......

@adg @quentinmit @rsc apa langkah selanjutnya untuk proposal ini?

Akan sangat senang melihat sesuatu terjadi di sini. itu adalah titik nyeri yang sering terjadi di kelas saya. Default apa pun (bahkan $home/go yang saya tidak setujui :) ) lebih baik daripada tidak sama sekali.

$HOME/pergi itu akan menjadi. Tidak ada satu jawaban terbaik tetapi ini singkat dan manis, dan hanya akan menjadi masalah untuk memilih nama itu jika $HOME/go sudah ada, yang hanya akan menyenangkan bagi para ahli yang sudah menginstal dan akan memahami GOPATH.

Siapa yang mau mengerjakan?

Saya pasti akan senang untuk mengerjakan ini.

@campoy , bisakah kamu melakukannya <= Jumat ini?

Saya akan mengatakan demikian, ya @bradfitz . Kedengarannya tidak seperti sejumlah besar kode yang harus dilakukan.
Aku bisa mulai besok.

pembaruan: Saya telah melihat sekilas ini dan sudah menulis beberapa kode, akan menambahkan beberapa tes dan mengirim perubahan nanti hari ini

Ini adalah orang-orang hebat! 👍

@robpike apakah Anda mempertimbangkan juga proposal alternatif saya di #17271? Saya ingin memahami mengapa proposal ini dianggap lebih baik

Bukan ide yang baik untuk memiliki nama direktori instal Go dan direktori ruang kerja yang sama yaitu go karena:

1) Sangat mudah bagi pengguna yang naif untuk merusak/mencemari ruang kerja jika pengguna melakukan tar -xzf go$VERSION.$OS-$ARCH.tar.gz di direktori home

2) Pengalaman default pengguna baru saat tidak menginstal di /usr/local (tidak ingin menginstal sebagai root) tidak akan mulus karena ini akan menjadi alurnya:
Unduh go$VERSION.$OS-$ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> instal di $HOME/go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> melempar cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas itu adalah pemahaman saya bahwa jika GOROOT=$HOME/go , default ini tidak akan terjadi atau membuat go kesalahan karena GOROOT dan GOPATH tidak bisa sama. Dalam kasus seperti itu, seperti yang dikatakan sebelumnya, diharapkan pengguna cukup mampu untuk mengatur GOPATH mereka sendiri.

@mvdan benar, untuk pengguna baru yang tidak ingin menggunakan hak akses root untuk instalasi (dan karenanya kemungkinan besar untuk menginstal Go in ~/go) kami tidak membuatnya lebih mudah untuk menyiapkan dan menjalankannya karena mereka harus secara eksplisit atur GOPATH ke sesuatu yang lain. Ini dapat dengan mudah diperbaiki jika GOPATH default adalah ~/gopath atau ~/gocode

Untuk instalasi non-root, jika pengguna baru harus memanfaatkan default GOPATH=~/go maka dokumentasi instalasi harus dibuat sedikit lebih rumit dengan secara eksplisit meminta pengguna untuk menggunakan opsi tar -C agar tidak menginstalnya di ~/go

@rasky saya menganggap #17271 dan proposal ini sebagai ortogonal. Resolusi proposal ini adalah kemenangan mudah yang tidak mendorong kita ke arah tertentu. Saya akan menguraikan lebih lanjut tentang masalah itu.

Saya setuju dengan @krishnasrinivas. Saya tidak memiliki izin root, jadi saya hanya menghapus tautan Go to $HOME/go. Saya juga mengatur $GOPATH=$HOME/gowork.

@krishnasrinivas @joegrasse Tidak ada solusi yang sempurna. Sangat mudah untuk mengatur sendiri GOPATH , dan saya berharap itulah yang akan dilakukan kebanyakan orang. Masalahnya di sini adalah apa yang harus kita lakukan untuk orang-orang yang baru menggunakan Go. Ini bukan pada umumnya orang yang memasang distribusi Go mereka sendiri di lokasi khusus. Orang yang dapat mengetahui cara memasang Go di lokasi khusus dapat mengetahui cara menyetel GOPATH .

Pikirkan alih-alih kelas programmer baru yang menggunakan distribusi Go yang sudah diinstal sebelumnya. Kami ingin mereka dapat mulai menulis kode Go. Kami tidak ingin langkah pertama menjadi "inilah variabel lingkungan. Beginilah cara Anda menyetelnya. Sekarang setel GOPATH ke ini." Langkah-langkah itu tidak ada hubungannya dengan Go.

Sekali lagi, tidak ada solusi yang sempurna, tetapi tampaknya bijaksana untuk memilih sesuatu.

@ianlancetaylor Saya sepenuhnya setuju bahwa ada sesuatu yang harus dipilih. Saya hanya percaya dengan go untaring ke ./go, default ke $HOME/go, mungkin bukan pilihan terbaik.

@ianlancetaylor GOPATH=$HOME/gopath adalah default yang lebih baik daripada GOPATH=$HOME/go karena alasan yang disebutkan di atas.

Saya tidak berpikir nama saat ini adalah masalah - jika Anda tahu cara mengatur PATH untuk lokasi go/bin khusus di bawah homedir Anda, Anda tahu cara mengatur GOPATH.

@joegrasse @krishnasrinivas Lihatlah " Menginstal ke lokasi khusus ".

Jika Anda menghapus tar ke mana pun selain /usr/local/go -- karena alasan izin atau lainnya -- Anda juga perlu menyetel GOROOT, atau mengompilasi dari sumber.

Selama itu masalahnya, tidak ada manfaat menggunakan $HOME/gopath, dll. daripada $HOME/go yang diusulkan.

Anda berasumsi bahwa pengguna baru lebih suka menginstal dari tar.gz. Saya dapat mengutip tidak
angka, tetapi percayalah bahwa jawaban Anda didasarkan pada instalasi Linux, yang
adalah target instalasi terpopuler ketiga untuk go.

Pada Sel, 25 Okt 2016, 20:28 Krishna Srinivas [email protected]
menulis:

@mvdan https://github.com/mvdan benar, untuk pengguna yang tidak mau
gunakan hak akses root untuk instalasi (dan karenanya kemungkinan besar untuk menginstal
Masuk ~/go) kami tidak membuatnya lebih mudah untuk menyiapkan dan menjalankannya sebagai
mereka harus secara eksplisit mengatur GOPATH ke sesuatu yang lain. Ini bisa jadi
mudah diperbaiki jika GOPATH adalah ~/gopath atau ~/gocode

Untuk instalasi non-root, jika pengguna baru harus memanfaatkan default
GOPATH=~/go maka dokumentasinya harus dibuat sedikit lebih rumit
dengan secara eksplisit meminta pengguna untuk menggunakan opsi tar -C agar tidak menginstalnya di
~/pergi

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

Semua dokumen juga perlu diperbarui. Itu mungkin sebagian besar pekerjaan.

Pada 25 Oktober 2016 pukul 10:14, Francesc Campoy [email protected]
menulis:

Saya akan mengatakan demikian, ya. Kedengarannya tidak seperti sejumlah besar kode yang harus dilakukan.
Aku bisa mulai besok.

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

Saya akan mengatakan demikian, ya. Kedengarannya tidak seperti sejumlah besar kode yang harus dilakukan.
Aku bisa mulai besok.

Pada Senin, 24 Okt 2016 jam 16:05 Brad Fitzpatrick [email protected]
menulis:

@campoy https://github.com/campoy , dapatkah Anda melakukannya sebelum <= Jumat ini?

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

Saya dapat membantu dengan dokumen jika perlu. Satu-satunya masalah adalah materi saat ini hanya bergantung pada GOPATH sebagai titik referensi. Sebagai contoh,

"Atau, karena Anda telah menambahkan $GOPATH/bin ke PATH , ketik saja nama binernya:"

atau

"Buat paket di bawah GOPATH, mkdir -p $GOPATH/src/github.com/user/hello"

Tanpa terlibat dengan GOPATH dan mempelajari apa itu, hampir tidak mungkin menyelesaikan apa pun di Go selain mendapatkan paket pihak ketiga. Jika kami dapat melaporkan jalur default melalui go env , itu akan mudah untuk merujuknya di dokumen.

Mungkin $HOME/go/... bisa diganti (atau yang setara di Windows)?

Karena Anda telah menambahkan $HOME/go/bin ke PATH Anda (atau $GOPATH/bin jika GOPATH disetel)...

Mungkin di beberapa titik dokumentasi dapat mengharapkan individu untuk tidak hanya mengatur variabel lingkungan PATH, tetapi juga mengatur GOPATH ke $HOME/go. Meskipun berlebihan, ini mempersiapkan pengguna untuk referensi selanjutnya ke GOPATH.

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan variabel lingkungan sama sekali.

Anda berasumsi bahwa pengguna baru lebih suka menginstal dari tar.gz. Saya dapat mengutip tidak
angka, tetapi percayalah bahwa jawaban Anda didasarkan pada instalasi Linux, yang
adalah target instalasi terpopuler ketiga untuk go.

Anda benar, pendapat saya bias terhadap instalasi Linux. Saya dapat melihat bahwa untuk pengguna baru yang menginstal go di /usr/local, ~/go mungkin nama direktori yang lebih dikenal daripada ~/gopath

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan
variabel lingkungan sama sekali?

Yup, semoga semua perdebatan yang mengganggu tentang setting GOPATH bisa dipindahkan
ke lampiran dokumentasi instalasi, seperti yang kami lakukan untuk GOROOT
saat ini.

Pada Rabu, 26 Okt 2016, 06:01 Nathan Youngman [email protected] menulis:

Mungkin $HOME/go/... bisa diganti sebagai gantinya (atau yang setara di
jendela)?

Karena Anda telah menambahkan $HOME/go/bin ke PATH Anda (atau $GOPATH/bin jika GOPATH adalah
mengatur)...

Mungkin di beberapa titik dokumentasi bisa mengharapkan individu untuk tidak
hanya mengatur variabel lingkungan PATH, tetapi juga mengatur GOPATH ke $HOME/go.
Meskipun berlebihan, itu membuat dokumentasi selanjutnya menjadi jelas.

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan lingkungan
variabel sama sekali?

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

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan variabel lingkungan sama sekali.

SGTM

Ada dua jenis pengguna Go:

• Pengguna yang baru saja mendapatkan paket yang ada
• Pengguna yang merupakan pengembang Go

GOPATH default sedang memperbaiki kasus untuk grup pertama. Kami masih dapat menyimpan instruksi terkait GOPATH untuk dokumen yang dihadapi pengembang. Instalasi tidak perlu menyebutkan pengaturan GOPATH sama sekali lagi atau kita dapat memiliki lampiran seperti yang disebutkan @davecheney .

Sebagai seseorang yang harus mengganti nama ~/bin/go karena Go, saya ingin menyarankan bahwa apa pun defaultnya, jika sudah ada maka harus memiliki .dotfile di dalamnya untuk menunjukkan itu benar-benar Go ~/go. Ketika ~/go tidak ada, go dapat membuatnya, membuat .dotfile, dan proses selanjutnya dapat menemukannya. Jika saya secara eksplisit mengatur GOPATH ke ~/go maka tidak ada .dotfile yang diperlukan karena tidak ada nilai default yang digunakan.

Dotfile ada. Ini adalah direktori src/ di dalam $HOME/go.

Pada Rabu, 26 Oktober 2016, 07:59 RalphCorderoy [email protected] menulis:

Sebagai seseorang yang harus mengganti nama ~/bin/go karena Go, saya ingin menyarankan
bahwa apapun defaultnya, jika sudah ada maka harus memiliki
.dotfile di dalamnya untuk menunjukkan itu benar-benar Go ~/go. Ketika ~/go tidak ada,
go dapat membuatnya, membuat .dotfile, dan proses berikutnya dapat menemukannya. Jika saya
secara eksplisit mengatur GOPATH ke ~/go maka tidak ada .dotfile yang diperlukan karena tidak
nilai default sedang digunakan.

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

CL https://golang.org/cl/32019 menyebutkan masalah ini.

Bahkan jika beberapa programmer tidak mengetahui variabel lingkungan, mereka
setidaknya harus akrab dengan _variables_. Saya pikir kita akan membutuhkan
untuk menggunakan sesuatu untuk mendeskripsikan lokasi ruang kerja di dokumen, dan
string $GOPATH mungkin juga demikian.

Pada 26 Oktober 2016 pukul 06:24, Jaana Burcu Dogan [email protected]
menulis:

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan lingkungan
variabel sama sekali.

SGTM

Ada dua jenis pengguna Go:

• Pengguna yang baru saja mendapatkan paket yang ada
• Pengguna yang merupakan pengembang Go

GOPATH default sedang memperbaiki kasus untuk grup pertama. Kita masih bisa menjaga
Petunjuk terkait GOPATH untuk dokumen yang dihadapi pengembang. NS
instalasi tidak perlu menyebutkan pengaturan GOPATH sama sekali atau kami
dapat memiliki lampiran sebagai @davecheney https://github.com/davecheney
menyebutkan.

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

Terima kasih niatnya, silakan lihat proposal aslinya.

Akibatnya kita sekarang dapat mengatakan "go get will download source to a folder
dipanggil, go/src/github.com/Foo/Bar di dalam direktori home Anda"

Pada Rabu, 26 Okt 2016, 06:01 Nathan Youngman [email protected] menulis:

Mungkin $HOME/go/... bisa diganti sebagai gantinya (atau yang setara di
jendela)?

Karena Anda telah menambahkan $HOME/go/bin ke PATH Anda (atau $GOPATH/bin jika GOPATH adalah
mengatur)...

Mungkin di beberapa titik dokumentasi bisa mengharapkan individu untuk tidak
hanya mengatur variabel lingkungan PATH, tetapi juga mengatur GOPATH ke $HOME/go.
Meskipun berlebihan, itu membuat dokumentasi selanjutnya menjadi jelas.

Dokumentasi awal dapat mengasumsikan default dan tidak menyebutkan lingkungan
variabel sama sekali?

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

Ini akan menjadi masalah besar untuk minggu terakhir Hacktoberfest

Dotfile ada. Ini adalah direktori src/ di dalam $HOME/go

"src" adalah cara yang umum untuk menjadi "ini dibuat sebagai default GOPATH oleh Go" dotfile.

Apa hal yang Anda coba cegah?

Pada hari Rabu, 26 Okt 2016 jam 09:20, RalphCorderoy [email protected]
menulis:

Dotfile ada. Ini adalah direktori src/ di dalam $HOME/go

"src" adalah cara yang umum untuk menjadi "ini dibuat sebagai GOPATH default oleh
Pergi" dotfile.

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

$HOME/pergi itu akan menjadi.

Apa yang akan terjadi untuk pengguna Windows?

Alex

Pengguna Windows akan menggunakan %USERPROFILE%\go , sama seperti yang dilakukan Docker di sini .

@davecheney , saya mencoba untuk mencegah apa yang saya katakan dua jam yang lalu: https://github.com/golang/go/issues/17262#issuecomment -256173981

Pergi adalah kata yang umum. Saya memiliki ~/bin/go. Orang-orang bermain Go dan memiliki kode sumber yang berkaitan dengan bermain go. Nabbing ~/go secara default ketika sudah ada hanya karena mengandung src tidak sopan. Jika ~/go tidak ada maka Go dapat mengambil nama, membuat direktori, menandainya sebagai golang dengan dotfile yang signifikan, misalnya berdasarkan nama domain golang.org.

Itulah masalahnya, dan solusi yang mungkin. Sekalipun solusinya tidak tepat, bukan berarti masalahnya tidak ada.

Saya memilih $ HOME/grup

Terima kasih.

Bisakah kita menggunakan default GOPATH sebagai ~/.gosrc ?

Bisakah kita menggunakan default GOPATH sebagai ~/.gosrc ?

Ini akan disembunyikan secara default di Linux dan OS X, dan terlihat di Windows. Apa motivasi untuk menyembunyikan GOPATH?

Diskusi tentang nilai default berlangsung sebulan yang lalu. Keputusan pada $HOME/go telah dilakukan dan sedang diimplementasikan. Kembali ke topik itu hanya akan membuat utasnya sangat panjang.

Orang-orang bermain Go dan memiliki kode sumber yang berkaitan dengan bermain go.

Saya tidak benar-benar mengikuti Anda, tetapi mengingat bahwa Anda telah menyetel GOPATH ke
sesuatu yang lain sudah, tidak akan ada dampak bagi Anda.

Pada hari Rabu, 26 Oktober 2016 pukul 09:43, RalphCorderoy [email protected]
menulis:

@davecheney https://github.com/davecheney , saya mencoba mencegah apa yang saya
mengatakan dua jam yang lalu: #17262 (komentar)
https://github.com/golang/go/issues/17262#issuecomment -256173981

Pergi adalah kata yang umum. Saya memiliki ~/bin/go. Orang-orang bermain Go dan memiliki kode sumber
hubungannya dengan bermain pergi. Nabbing ~/go secara default ketika sudah ada saja
karena kebetulan mengandung src tidak sopan. Jika ~/go tidak ada maka Go
dapat mengambil nama, membuat direktori, mencapnya sebagai golang dengan a
dotfile yang signifikan, misalnya berdasarkan nama domain golang.org.

Itulah masalahnya, dan solusi yang mungkin. Bahkan jika solusinya
tidak tepat, bukan berarti tidak ada masalah.

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

Hai @davecheney , Masalah ini dimulai dengan Anda mengusulkan ~/gocode. Seiring waktu, itu menjadi ~/go. @robpike mengatakan di atas "hanya bisa menjadi masalah untuk memilih nama itu jika $HOME/go sudah ada, yang hanya akan menyenangkan bagi para ahli yang sudah menginstal dan akan memahami GOPATH". Saya pikir dengan terbungkus golang begitu lama, Anda bersama-sama melupakan betapa umum kata "pergi", dan bagaimana kata itu memiliki arti lain, seperti permainan papan.

Perubahan ini ditujukan untuk pendatang baru di Go dan beberapa dari mereka mungkin sudah memiliki ~/go untuk penggunaan non-Go. Saya menyarankan jika go datang, menemukan GOPATH tidak disetel, dan tidak ada ~/go maka ia dapat membuatnya, mengambil namanya. Tetapi jika ~/go memang ada maka seharusnya hanya menggunakannya jika ia dapat memberitahunya bahwa ia membuatnya dalam doa tanpa GOPATH sebelumnya. Saya menyarankan dotfile dibuat sebagai flag ini. Anda mengatakan ~/go/src akan berfungsi sebagai bendera itu. Keberatan saya adalah src itu sendiri tidak biasa di antara programmer, yaitu mereka yang mungkin menginstal Go. Dotfile yang tidak biasa, misalnya ~/go/.default-gopath menghindari potensi bentrokan ini.

Jika mereka secara manual membuat ~/go untuk Go dan menjalankan go tanpa GOPATH maka itu tidak akan menggunakan ~/go karena dotfile hilang. Saya pikir ini tidak apa-apa karena dengan mulai menyiapkan instalasi Go, mereka harus melanjutkan, mengatur GOPATH. Itu bukan kasus "instal paket, jalankan go(1)" sederhana yang ditargetkan.

Jika semua ini tidak dianggap sebagai masalah maka tidak apa-apa. Tetapi selama Anda mengeluh bahwa Anda tidak mengerti maksud saya, saya ditakdirkan untuk terus berusaha menjelaskannya.

Itu sebabnya saya awalnya menyarankan jalan yang berbeda, dengan saran Rob sekarang secara resmi di luar kendali saya.

Dengan itu, saya senang bahwa jalur _a_ telah dipilih karena saya melihatnya sebagai titik latihan.

Untuk masalah Anda, saya sarankan Anda mengikuti https://go-review.googlesource.com/#/c/32019/ di mana tepatnya masalah yang Anda khawatirkan sedang dibahas.

@RalphCorderoy , kekhawatiran Anda adalah programmer Go-the-board-game memiliki direktori ~/go untuk peretasan permainan papan?

Rob dan Russ sangat anti-dotfiles. Lebih baik menyatakan masalahnya daripada menyatakan jawabannya jika jawabannya melibatkan dotfiles (atau symlink).

@bradfitz , ya, ~/go sudah ada untuk pemain gogame, dan selanjutnya ~/go/src ada karena mereka programmer pemain gogame jika tidak mereka tidak akan mempermainkan Go. (Saya memiliki ~/chess/src saat itu terjadi.)

logika ringkasan adg https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c tampaknya baik-baik saja, dan saya lebih suka membuat ~/go jika tidak ada, tetapi test -d ~/go/src adalah tes terkelupas untuk menggunakan ~/go jika tidak ada GOPATH.

Jika bukan ~/go, tetapi sesuatu yang lebih tidak biasa, seperti saran asli Dave, maka itu tidak masalah. Saya pikir survei tentang apa yang saat ini digunakan yang menunjukkan ~/go sangat populer tidak terlalu membantu ketika pemilih adalah programmer Go yang cukup tertarik untuk mengikuti isu dan media sosial.

@RalphCorderoy Saya pikir jumlah perawatan dan celana dalam ganda yang direkayasa ke dalam CL 32019 lebih dari cukup untuk potensi ketidaknyamanan bagi sekelompok kecil pemrogram game-of-go yang _belum_ menggunakan Go sebelum versi 1.8 dan _belum_ disetel GOPATH _dan_ juga mulai belajar bahasa Go.

Alat go tidak akan menghapus atau merusak kode non go yang ditemukan, Anda hanya akan mendapatkan pesan yang sedikit membingungkan dalam situasi _few_. Untuk menjelaskan hal ini, alat go tidak akan membuat sumber Go di atas $GOPATH/src karena kode tersebut tidak berada dalam paket yang dapat diimpor. Selain itu, tujuan lain dari perubahan ini adalah untuk mempermudah go get beberapa kode dengan menyediakan lokasi default untuk mengunduh sumber, jadi _if_ ada kode sumber game-of-go di ~/go/src , kemungkinannya bertentangan dengan subdirektori yang berasal dari repositori go gettable sangat kecil, dan bahkan jika itu terjadi, alat go atau git akan rusak sebelum data apa pun diubah.

Saya pikir situasi yang Anda khawatirkan sangat tidak mungkin, dan selanjutnya dikurangi dengan penjelasan di atas.

(Hanya argumen yang mungkin valid terhadap GOPATH=$HOME ): Apakah kinerja goimports ditangani? Saya ingat sesuatu tentang file .goimport_ignore . Jika tidak, kinerja editor populer bisa terganggu.

Dengan demikian, GOPATH!=$HOME kemungkinan merupakan opsi bebas tabrakan/tidak tercemar dan harus berkinerja baik.

@davecheney Setelah go get Saya harus membersihkan ~/go/{bin,src,pkg} dan itu bukan pengantar yang bagus untuk Go setelah menempelkan baris yang saya temukan di Internet.

@RalphCorderoy harap dipahami bahwa tujuan dari perubahan ini adalah untuk memudahkan pengguna Go baru -- ini bukan Anda -- Anda sudah memiliki $GOPATH set, karena Anda _harus_ dengan setiap versi Go mulai dari 1.1 dan seterusnya. Tumpang tindih antara pengguna go-the-game dan _potential_ pengguna go-the-bahasa pemrograman sangat sangat kecil. Saya tidak berpikir akan ada masalah.

@RalphCorderoy Situasi yang Anda gambarkan jarang terjadi, dan siapa pun yang menjalankan perintah shell dari situs web acak seharusnya tidak berharap bahwa disk mereka tidak akan dihapus, apalagi beberapa file yang diunduh dan dikocok di direktori eponymous. (Sunting: Pertimbangkan Wine membuat dan memodifikasi .wine di direktori home pengguna secara otomatis. Bagaimana jika pengguna memiliki sesuatu yang lain di sana? Lagi pula, "anggur" adalah istilah yang kami gunakan untuk minuman tertentu.)

Tabrakan penamaan antara "Go" bahasa dan "Go" papan permainan tentu dipahami dan terkenal. Sistem file adalah sumber daya bersama, tabrakan terjadi dan tidak dapat dihindari.

@davecheney , Tolong berhenti memberi tahu saya bahwa perubahan ini tidak ditujukan untuk membantu saya karena saya bukan pengguna Go baru. Saya selalu menyadari hal itu bahkan sebelum Anda mulai menunjukkannya. Saya juga mengerti posisi Anda len(intersect(existing-~/go, GOPATH-less)) terlalu kecil untuk menjadi perhatian.

Setelah membersihkan go-get spew di ~/go karena dia tahu apa yang biasanya tidak ada di sana, dia kemudian harus meneliti untuk melihat apa lagi yang mungkin dilakukan perintah di bawah $HOME jika lebih pembersihan diperlukan.

berhenti berlangganan

Saya minta maaf jika saya telah menyebabkan Anda tersinggung. Saya tidak lagi ingin berkorespondensi
dengan Anda tentang masalah ini. Terima kasih.

Pada Jum, 28 Okt 2016 jam 3:28, RalphCorderoy [email protected]
menulis:

@davecheney https://github.com/davecheney , Tolong berhenti memberi tahu saya ini
perubahan tidak ditujukan untuk membantu saya karena saya bukan pengguna Go baru. saya sudah
selalu menyadari hal itu bahkan sebelum Anda mulai menunjukkannya. saya juga
pahami posisi Anda len(intersect(existing-~/go, GOPATH-less)) adalah
terlalu kecil untuk menjadi perhatian.

Setelah membersihkan go-get memuntahkan ~/go karena dia tahu apa
biasanya tidak ada di sana, dia kemudian harus meneliti untuk melihat apa lagi—
command(s) mungkin telah dilakukan di bawah $HOME jika diperlukan lebih banyak pembersihan.

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

davecheney, Tidak, bukan pelanggaran. Tidak ada gunanya terus menutupi tanah yang sama.

Hanya ingin tahu – apa perilaku yang diharapkan jika $HOME tidak disetel?

Sementara saya tidak pernah bekerja pada sistem di mana itu terjadi, tampaknya mungkin seseorang telah memodifikasi env vars default mereka untuk beberapa alasan, dan kasus tepi ini harus ditangani secara konsisten.

Saya pikir saat ini mengevaluasi $GOPATH='' ; apakah itu berarti akan menggunakan direktori kerja saat ini?

gunakan direktori kerja saat ini

Terpikir oleh saya bahwa ini mungkin yang paling berguna untuk pengguna Go baru yang belum menyetel GOPATH. go get akan mirip dengan wget, dll., mengisi direktori saat ini. Mereka tidak tertarik pada aspek jalur GOPATH pada saat ini, dan sangat mungkin ingin setiap usaha mereka bermain-main dengan hal-hal online yang berbeda menjadi berbeda, karena direktori sementara baru yang mereka buat sendiri akan memberi mereka. Mereka bisa mendapatkan, menjalankan, dan dengan mudah menghapus, berbagai repo yang mereka lihat direferensikan.

• jika GOPATH tidak disetel:
  
  
  
  • jika hanya satu atau dua, tetapi tidak semua, dari ~/{bin,pkg,src} ada:
  
  
  • mereka harus mengatur GOPATH, pkg adalah yang tidak biasa
  
  
  • lain baik semua atau tidak ada:
  
  
  • pastikan mereka semua ada
  
  
  • GOPATH=$(pwd)
  
  

Saya memiliki perasaan campur aduk tentang ini, tetapi sentimen saya yang berlaku (sebagai seseorang yang telah menetapkan $GOPATH ) adalah bahwa perilaku go get harus "deterministik" dan selalu menginstal hal-hal di bawah $GOPATH – tujuan yang konsisten dan terdokumentasi dengan baik.

Meskipun saya tidak terpengaruh oleh perubahan ini, rasanya aneh bahwa go get akan mengunduh sesuatu ke lokasi yang berbeda tergantung pada direktori kerja saat perintah dikeluarkan. Saya sadar inilah yang dilakukan wget , npm install , dan alat lain, tetapi rasanya seperti menyimpang dari gagasan nilai $GOPATH konsisten (begitulah cara saya menafsirkan semangat perubahan ini).

Jika ini di luar cakupan masalah ini, saya akan mengusulkan untuk keluar dan mengeluarkan kesalahan jika $HOME sebenarnya tidak disetel.

Saya telah mengajar 5 programmer baru yang berasal dari dunia Java di negara dunia ke-3.. Mereka semua pasti bingung tentang GOPATH. Heck, saya juga ketika saya mulai kembali sebelum Go 1 dirilis. Saya pribadi menggunakan "$HOME/gopath" tetapi saya menyarankan agar perintah "go get" mengarahkan mereka ke blog go yang JELAS tentang cara membuat jalur go untuk sistem operasi mereka. Itu saja yang kita butuhkan. Beberapa panduan dengan perintah "go get" yang bukan merupakan spesifikasi.. Tapi posting blog yang sangat sederhana!!

Jelas maksud saya ketika tidak ada GOPATH yang ditetapkan. Cukup perbarui pesan kesalahan yang saat ini ditampilkan. Tingkat adopsi sudah ada .. Hanya perlu sedikit bantuan daripada metode google it up saat ini yang dilakukan pendatang baru.

@einthusan Saya merasa itu cukup terdokumentasi dengan baik di https://golang.org/doc/code.html#GOPATH , tapi saya tidak tahu berapa banyak orang yang memulai dengan Go yang benar-benar membaca halaman ini.

Maaf untuk spam.. Setelah melakukan beberapa googling.. Saya pikir "go get" seharusnya hanya meminta pengguna mengatakan "Tidak ada GOPATH yang telah disetel... Apakah Anda ingin menggunakan direktori kerja saat ini sebagai GOPATH sementara Anda?" (Ya Tidak)

@einthusan , tidak ada preseden untuk cmd/go melakukan prompt interaktif.

Jika GOPATH default baru adalah $HOME/go. Tidakkah orang mengharapkan https://hub.docker.com/_/golang/ ini mengadopsi perilaku yang sama?

@cescoferraro itu pertanyaan untuk pengelola gambar itu. Meskipun diberi label sebagai "resmi", proyek itu tidak berafiliasi dengan Go.

Menjawab/menanggapi pertanyaan saya sendiri tentang unset $HOME :

Dalam implementasi saat ini (CL ditautkan di atas), $GOPATH default ke "" jika $HOME tidak disetel: https://go-review.googlesource.com/#/ c/32019/11/src/go/build/build.go Saya pikir ini konsisten dengan perilaku saat ini.

Saya percaya kasus tepi ini sangat tidak mungkin karena $HOME selalu disetel dalam sesi login normal, yang mungkin terjadi pada sebagian besar pemrogram Go. Meskipun saya pribadi akan _suka_ perilaku untuk diklarifikasi secara eksplisit, sepertinya tidak ada "efek samping" (seperti menginstal sesuatu di direktori kerja). Koreksi saya jika saya salah. :)

Jika ini untuk memudahkan orang yang memulai dengan Go untuk pertama kalinya, biarkan seperti jalur saat ini:

GOPATH=$(pwd)

Menyetel export GOPATH=$(pwd) memudahkan peralihan antar proyek

Perilaku yang saya usulkan untuk perubahan ini:

Variabel lingkungan

• Jika GOPATH disetel, alat akan berperilaku seperti biasanya
• Jika tidak, kami memeriksa variabel lingkungan HOME ( home untuk plan9, USERPROFILE untuk windows).
  
  
  
  • Jika variabel env tidak disetel maka GOPATH juga tidak akan disetel: ini berarti "go get" akan gagal dengan cannot download, $GOPATH not set.
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• Jika tidak GOPATH akan ditetapkan sebagai $HOME/go ( $home/go , %USERPROFILE%\go ).

> unset GOPATH
> go env GOPATH
/Users/campoy/go

kreasi GOPATH

Saat ini jika $GOPATH tidak ada, itu dibuat ketika kita menjalankan go get import/path . Ini tidak akan berubah.

Satu-satunya perubahan adalah jika $GOPATH tidak disetel di lingkungan pengguna (yaitu echo $GOPATH tidak menampilkan nilai), pemeriksaan tambahan dilakukan untuk memastikan nilai default dapat diterima:

• jika GOPATH tidak disetel dan tidak ada nilai default yang dibuat: perintah akan gagal

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

• jika default $GOPATH tidak ada peringatan akan ditampilkan menjelaskan bahwa direktori telah dibuat, menunjuk ke go help gopath untuk info lebih lanjut.

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

• jika default $GOPATH ada:
  
  
  
  • dan ini bukan direktori: perintah akan gagal (seperti sebelumnya)
  
  

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

• dan itu adalah direktori kosong atau direktori yang memiliki subdirektori bernama src perintah akan berhasil (tidak ada peringatan)

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

• dan itu adalah direktori yang tidak kosong tanpa subdirektori bernama src perintahnya akan gagal

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

Jadi hanya peringatan baru yang disertakan setiap kali direktori dibuat menggunakan default GOPATH .

@campoy proposal perilaku tampak hebat.

Tetapi sekali lagi sebagai pengguna tingkat lanjut, saya ingin tahu berapa banyak dari kita yang serius menggunakan $HOME/go sebagai GOPATH setiap hari? Saya bahkan berpikir mungkin harus ada perintah go untuk mengatur GOPATH mirip dengan memulai env virtual pada direktori kerja python.

Karena saya mengerjakan banyak proyek, saya biasanya melakukan sesuatu seperti ini:

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

@jinmatt
Perubahan ini hanya mengubah perilaku untuk GOPATH yang tidak disetel, itulah ruang lingkup perubahannya.
Komunitas telah mencapai kesepakatan tentang $HOME/go.

Jika Anda tidak suka $HOME/go , cukup setel GOPATH ke nilai apa pun yang Anda inginkan (misalnya $HOME dalam kasus saya).

Terima kasih atas sketsa desainnya.

1. Karena kita sekarang telah menetapkan bahwa GOPATH hanya akan dibuat selama 'go get', mari kita hanya mencetak pesan jika flag -v diberikan, konsisten dengan perilaku 'go get -v' lainnya.
2. Jika direktori dibuat, pesannya harus paling banyak

# membuat GOPATH=/users/campoy/go; lihat 'pergi bantu gopath'

Ini bukan peringatan: peringatan itu buruk. Di sisi lain jika pembuatannya gagal maka Anda mungkin ingin mencetak

go: creating GOPATH=/users/campoy/go: %v

Kedua pesan tersebut dapat dicetak terlepas dari apakah GOPATH disimpulkan atau diatur secara eksplisit.

1. Heuristik tentang direktori kosong dan memiliki subdirektori src terlalu rumit. Lebih buruk lagi, mereka menangani masalah hipotetis, dan hipotetis sangat sulit untuk dirancang. Lebih baik memiliki perilaku yang lebih sederhana dan dapat diprediksi. Untuk memulai, saya pikir masuk akal untuk tidak memiliki aturan apa pun, sampai ada contoh nyata dari masalah aktual. Akan ada waktu bagi orang-orang untuk melaporkan masalah selama beta dan kandidat rilis. Mari kita atur saja GOPATH=$HOME/go (asalkan $HOME disetel).

Sunting: berpura-pura bahwa penurunan harga Github tidak sepenuhnya mengacaukan ini.

@campoy Mengenai src/ , apa perilaku go get saat ini ketika GOPATH disetel tetapi tidak ada direktori src? Apakah ada alasan bagus untuk tidak membuatnya juga?

Tampaknya lebih mudah untuk menjelaskan jika $HOME/go/src dibuat pada go get pertama (atau $GOPATH/src jika variabel lingkungan itu disetel)

Hari ini, ketika GOPATH diatur, direktori yang diperlukan dibuat, tanpa syarat, sesuai kebutuhan.

CL https://golang.org/cl/33356 menyebutkan masalah ini.

CL https://golang.org/cl/33730 menyebutkan masalah ini.