Go: cmd/go: 설정되지 않은 경우 GOPATH=$HOME/go로 가정

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

나는 그것을 좋아하지만 "gopath"와 같은 것이 아니라 "gocode"에 대한 특정 선호도가 있습니까?

얼마나 많은 사람들이 이미 GOPATH=$HOME/gocode를 사용하고 있습니까? 많지 않은 것 같습니다. 이는 잘못된 기본값임을 나타냅니다.

"gocode"는 인기 있는 도구인 github.com/nsf/gocode와 검색 엔진 및 기타 혼동을 일으킬 것입니다.

대부분의 사람들이 하는 일에 대한 정보가 있습니까?

나는 GOPATH=$HOME/gopath를 사용한다.

현재 GOPATH=$HOME을 사용하는 경우 여기를 추천합니다.

현재 GOPATH=$HOME/gopath를 사용하는 경우 여기를 추천합니다.

현재 GOPATH=$HOME/gocode를 사용하는 경우 여기를 추천합니다.

@golang에서 트위터 투표를 해야 하나요?

@campoy , 좋은 소리. 아마도 이 버그에 모든 사람을 초대하는 것보다 나을 것입니다.

$HOME/go는 어떻습니까(제가 사용하는 것입니다).

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

$홈: 8.9%
$HOME/go: 50.6%
기타 : 40.5%

이 옵션에 대해 더 많은 옵션을 분할했으면 합니다.

투표 시작: https://twitter.com/golang/status/781189567437164544

2016년 9월 28일 수요일 오전 10:51 Edward Muller [email protected]
썼다:

$HOME/go는 어떻습니까(제가 사용하는 것입니다).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -250244110 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

여기에서 1열도 참조 하십시오.

@freeformz ,

$HOME/go가 go 소스 코드(go.googlesource.com/go)가 자주 체크아웃되는 경로와 충돌합니다. 커뮤니티가 이 위치를 GOPATH의 기본값으로 축복했다는 것은 좋지 않습니다.

@rakyll 은 저와 다른 많은 사람들이 사용하는 것을 표시하고 싶었습니다. go.googlesource.com/go는 내 시스템의 /usr/local/go.git에서 체크아웃됩니다.

얼마나 많은 사람들이 이미 GOPATH=$HOME/gocode를 사용하고 있습니까? 많지 않은 것 같습니다. 이는 잘못된 기본값임을 나타냅니다.

기록을 위해 나는 GOPATH=$HOME 를 사용하지만 이것이 너무 논쟁의 여지가 있고 새로운 사용자를 위한 경험을 개선하는 이 제안의 목표를 손상시킬 것이라고 생각했습니다.

@freeformz , 우리는 $HOME 외부에 있는 기존 정식 경로에 대해 신경 쓸 필요가 없다고 생각합니다. GOPATH의 기본값은 $HOME 어딘가에 있으며 최소한의 요구 사항은 중요한 기존 경로와 충돌하지 않아야 한다는 것입니다.

$HOME/gocode는 나에게 생소하게 들리지만 아주 좋은 선택이 될 수 있습니다.

요점은 기본값이 무엇인지는 중요하지 않고 기본값이 있다는 것입니다.

기본값이 무엇인지는 중요하지 않습니다. 이 기본값을 설정하면 기본적으로 Go를 처음 접하는 모든 사람들이 지금부터 몇 년 동안 어떻게 작업하는지가 되기 때문입니다.

go 명령은 GOPATH=$GOROOT일 때 혼동되지 않도록 명시적으로 진행됩니다. 암묵적 설정에도 동일한 논리를 적용할 수 있다고 확신합니다. 따라서 실수로 $HOME/go를 스매싱하는 것에 대해 너무 걱정하지 않습니다.

나는 여전히 고정된 기본값 대신 GOPATH가 어디에 있는지 알아내기 위해 현재 디렉토리의 부모를 자동 스니핑해야 하는지 궁금합니다. 이것은 오늘날 많은 소스 도구(예: 모든 버전 제어 시스템)가 수행하는 작업이므로 사람들이 이해할 수 있는 개념입니다. 그리고 하나의 디렉토리 이름을 사용하거나 하나의 GOPATH 작업 공간만 갖도록 강요하지 않습니다. 그러나 우리는 원래 문제에 대해 그 논의를 할 수도 있습니다.

@rsc 나는 그 기본값이 GOPATH=$HOME 이길 원합니다. 왜냐하면 그것은 $GOPATH/bin 가 그들의 경로에 있을 것이라는 것을 의미하기 때문입니다(적어도 대부분의 Linux 배포판에서는 darwin에 대해 확신하지 못합니다).

$GOPATH=$HOME/go 도 좋은 선택이고 컴파일러의 소스를 체크아웃한 사람들은 이미 GOPATH=something else 했기 때문에 충돌 가능성이 없습니다.

분명히 말해서, 나는 경솔하게 말하려고 한 것이 아닙니다.

요점은 기본값이 무엇인지는 중요하지 않고 기본값이 있다는 것입니다.

오히려 이 제안의 목표를 강조하려는 시도는 go 도구가 $GOPATH 대한 기본값을 사용하도록 하는 것입니다. 왜냐하면 이것이 언어를 처음 접하는 많은 사람들에게 혼란과 좌절의 지속적인 원인이 되기 때문입니다.

자동 스니핑을 사용 중입니다. 다음과 같은 주요 사용 사례에 실패했기 때문입니다.

1. Go를 설치했지만 실제로 Go 설치 문서를 읽지 않고 brew install go 라는 repo의 README에서 말한 대로 따랐습니다.
2. go get github.com/thething/theproject
3. 이제 $GOPATH를 설정하지 않는다는 오류가 발생합니다. 저게 뭐에요? 누군가 트윗한 이 프로그램을 실행하고 싶었습니다!

GOPATH=$HOME/go SGTM의 기본값은 자동 스니핑 방식이 아닌 기본값을 결정한다고 가정합니다.

go 명령은 GOPATH=$GOROOT일 때 혼동되지 않도록 명시적으로 진행됩니다. 암묵적 설정에도 동일한 논리를 적용할 수 있다고 확신합니다.

잘 들린다.

다윈에 대해 확신이 없다

다윈에는 없습니다.

이것이 새 사용자를 위한 것이라면 GOPATH=$HOME 에 대해 조언할 것입니다. 그렇게 하면 홈 디렉토리에 하나가 아닌 세 개의 디렉토리가 생성되기 때문입니다. 나는 필요 이상으로 내 홈 디렉토리를 오염시키는 소프트웨어에 열중하지 않습니다.

@mvdan 이해하고 당신의 반응은 내가 GOPATH=$HOME 제안하지 않은 이유입니다.

_I_ 개인적으로 GOPATH 를 $HOME 로 설정하려면 해당 옵션을 계속 사용할 수 있으며 이 제안이 Go 1.8에 대해 수락되더라도 변경하지 않아야 합니다.

@davecheney

기본값은 GOPATH=$HOME/gocode 값입니다.

Windows에는 기본 HOME 변수가 없습니다. Windows에서 무엇을 할 것을 제안합니까?

$GOPATH/bin이 경로에 있음을 의미하기 때문에 기본값을 GOPATH=$HOME으로 설정하고 싶습니다.

나는 항상 내 PATH에 $GOPATH/bin이 있는지 걱정합니다. go get 는 다른 사람의 프로그램을 거기에 설치합니다. 새로운 Go 사용자가 PATH 어딘가에 인터넷에서 임의의 프로그램을 설치하기를 정말로 원합니까?

알렉스

저는 숙련된 Windows 사용자는 아니지만 문서와 설정이 저장되는 기본 경로에 대한 개념이 있다고 가정합니다. 이 토론의 목적을 위해 내가 Windows 사용자의 컨텍스트에서 해당 경로에 대해 이야기하고 있다고 가정합니다.

그러한 경로가 없으면 C:/gocode로 가정합니다.

GOPATH=$HOME에 대한 내 의견에 대한 글입니다. 이것은 내 개인 취향이며 앞으로도 계속 그럴 것이지만 이것이 기본값에 대한 논쟁의 여지가 있는 옵션이며 제안된 값으로 제안하지 않았음을 알고 있습니다.

자동 감지에는 위험이 따릅니다. 나는 이것을 얼마 전에 프로토타이핑하기 시작했지만 이동 도구와 사용자 경험 모두에 상당한 복잡성을 추가했습니다.

나는 패키지 관리 작업 그룹에서 무슨 일이 일어나고 있는지에 대해 이야기하고 있지 않지만 GOPATH가 완전히 제거되는 멀지 않은 미래를 상상할 수 있습니다.

즉, 가까운 장래에 GOPATH가 사라지더라도 기본값을 설정하는 데 여전히 가치가 있을 수 있습니다. GOPATH가 사라질 가능성이 있다고 생각한다면, 우리가 무엇을 설정했는지는 그다지 중요하지 않습니다.

위에서 읽은 내용에서 다음과 같은 합의가 있습니다.

1. 기본적으로 GOPATH=$HOME 는 너무 공격적입니다.
2. 기본값은 어딘가에 go 문자열을 포함해야 합니다(접두사일 가능성이 높음).

나는 GOPATH가 메인 go repo(즉, GOPATH == GOROOT)의 복제본이 되는 것에 대해 걱정하지 않는다. go repo를 체크아웃하는 사람들은 GOPATH 세트를 가지고 있을 것입니다. go 도구는 오늘날과 같이 어쨌든 충돌을 감지합니다.

이를 염두에 두고 가장 간결한 기본값은 $HOME/go 이며, 이는 상당히 합리적이라고 생각합니다.

문서와 설정이 저장되는 기본 경로에 대한 개념이 있다고 가정합니다.

나는 그런 것을 모른다. 아마도 다른 Windows 사용자가 여기에 댓글을 달 것입니다.

그러한 경로가 없으면 C:/gocode로 가정합니다.

대신 C:gocode를 원합니다.
C:\의 루트에 물건을 넣는 것은 나에게 옳지 않게 들립니다. Linux에서 GOPATH를 /gocode로 설정하도록 권장하시겠습니까?
그러나 Windows 설치 프로그램이 이미 Go into C:go를 설치한 경우 GOPATH용 C:gocode는 최소한 일관성이 있습니다.

알렉스

그러나 Windows 설치 프로그램이 이미 Go into C:go를 설치한 경우 GOPATH용 C:gocode는 최소한 일관성이 있습니다.

사용자별로 GOPATH를 제공하면 안되나요? UNIX와 동일하려면 %USERPROFILE%\gocode 라고 생각합니다.

https://goo.gl/xAsgEj 에서 Go+ 설문조사

$HOME/go-programs와 같은 것을 오랫동안 사용한 후 GOPATH를 $HOME으로 전환했습니다. 이제 다음 구조가 있습니다.

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

이 구조는 더 일반적이며 다른 언어나 프로젝트 및 github와 함께 사용하는 데에도 사용할 수 있습니다. 예를 들어 저는 $HOME/src/talks(마크다운 파일에 대해서는 home/sources/talks를 읽음) 또는 일부 언어($HOME/src/github.com/user/html과 같은)로 된 다른 프로젝트가 있지만 소스도 있고 하나가 있습니다. github 대응 여부에 관계없이 많은 프로젝트 소스를 위한 장소.

bin 또는 pkg는 지저분한 것으로 간주될 수 있지만 그렇게 성가시지는 않다고 생각합니다. 여러 언어를 사용하는 사람들을 위해 많은 소스 폴더가 있는 것은 더 지저분합니다.

그래서 내 관점에서 최고의 GOPATH 장소는 $HOME입니다.

내 GOPATH로 $HOME/gocode를 사용하고 있습니다.
때때로 루트 권한이 없고 홈 디렉토리 아래에 Go를 설치해야 하기 때문에 저는 $HOME/go에 반대합니다. 그런 경우에는 $HOME/go가 GOROOT에 가장 적합할 것이라고 생각합니다.
따라서 $HOME/go와 다른 것을 GOPATH로 사용해야 합니다.

@hnakamur 수동으로 Go를 설치할 때(지금 Ubuntu Make 사용), $HOME/bin/go-${go_version}에 넣었습니다($HOME/bin/go에서 $HOME/bin/go-$으로의 심볼릭 링크 사용) {version}/bin/go, 그래서 내 $PATH를 편집할 필요가 없었습니다)

@tbroyer 틈새 시장입니다. 대부분의 사용자는 추가 구성이나 설정을 원하지 않습니다. 내 생각에 ~/bin은 이미 (나처럼) 자신의 스크립트 또는 바이너리를 넣는 데 사용됩니다. 그리고 ~/bin (~/src, ~/pkg) 비트가 go 바이너리를 제거하기 어렵게 한다고 생각합니다.

내 GOPATH에 $HOME을 사용합니다.
GOPATH를 자동으로 설정하는 이유

GOPATH를 자동으로 설정하는 이유

문제는 사람들이 (대부분의 경우) 환경 변수를 설정하는 방법을 모른다는 것이 아니라, 설정하더라도 Go 사용을 시작하기 위해 여러 단계를 거쳐야 하는 것이 불편하다는 것입니다. Go를 설치하는 즉시 정상적인 기본 설정으로 사용할 수 있다는 것은 경험을 최대한 매끄럽게 만들고 더 많은 사람들이 다운로드 후 장애물을 만나 기세를 잃는 대신 실제로 Go를 시도할 가능성이 높다는 것을 의미합니다. 건드릴 가치가 없다고 판단합니다.

나는 Chris와 Andrew의 말에 동의하는 경향이 있습니다. 기본 GOPATH가 있어야 한다면 gopath나 gocode가 아니라 $HOME/go여야 합니다. _대부분의_ 사용자는 Go 배포판을 확인하지 않았습니다(오늘날 모든 사용자는 이미 GOPATH를 설정하므로 귀찮게 하지 않을 것입니다). 기본값은 고급 사용자가 아닌 신규 사용자에게 적합해야 하며 대부분의 사용자에게는 $HOME/go가 적합합니다.

Jaana는 $HOME/go가 Go 배포판인 경우 go 명령이 혼란스러워지는 것에 대한 우려를 제기했지만 go 명령은 이미 우발적인 GOPATH=$GOROOT를 확인합니다. GOPATH가 암시적으로 설정된 경우에도 이것이 사실인지 확인하는 것은 쉽습니다. 실제로 $HOME/go/src/cmd/go/alldocs.go와 같이 GOROOT!=$HOME/go가 있지만 $HOME/go가 실행되는 경우에도 혼동을 피하기 위해 검사를 확장하는 것도 쉽습니다. Go 배포판을 포함합니다.

$HOME/go는 GOPATH에 좋은 옵션이 아닙니다. 간단한 동작을 연습해 보겠습니다... 새로운 사용자는 기본값을 모범 사례처럼 쉽게 생각할 수 있습니다. 내가 새로운 사용자라고 가정해 보겠습니다. 왜 기본값을 나쁜 것으로 간주해야 합니까? 그 이상으로 golang을 설치하는 가장 쉬운(그리고 가장 좋은?) 방법은 $HOME에서 압축을 푸는 것입니다. 이 방법을 사용하면 컴파일러가 항상 마지막 버전에 있고 루트 권한이 필요하지 않기 때문에 많은 사용자가 컴파일러를 사용할 것이라고 쉽게 가정할 수 있기 때문입니다. $HOME/go에 있습니다. 단순히 할 수 없는데 왜 컴파일러를 /usr/local로 옮겨야 합니까?
그 이상으로 그들은 프로젝트를 만들고 이 폴더에서 프로젝트를 복제할 수 있습니다. 그래서 그들은 지저분한 폴더를 갖게 될 것이고 조금 부주의하면 새로운 golang 재설치로 프로젝트 폴더를 쉽게 삭제할 수 있습니다.
또한 Windows 사용자는 기본적으로 c:go를 사용합니다.

저는 $HOME/gopath를 좋아합니다. 그것이 무엇인지 말합니다.
"gopath"에 대한 Google의 첫 번째 결과는 올바른 페이지입니다.

기본값이 채택되면 func GOPATH() string 함수를 runtime 추가할 수 있습니까? 지금 당장은 os.Getenv() 사용할 수 있지만 기본적으로는 그렇게 간단하지 않을 것입니다.

@btracey , GOPATH는 단일 값이 아닌 목록입니다. filepath.SplitList 합니다. 또한 GOPATH는 런타임의 기능이 아닙니다. cmd/go 에만 해당됩니다.

이전 버전과의 호환성을 위해 아마도 프로세스에서 GOPATH를 설정해야 할 것입니다'
환경이 설정되지 않은 경우.

2016년 9월 30일 08:10, Brendan Tracey [email protected]
썼다:

기본값이 채택되면 func GOPATH() 문자열 함수를 추가할 수 있습니까?
런타임에? 지금은 os.Getenv()를 사용할 수 있지만 기본적으로
그렇게 간단하지 않을 것입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -250605418 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

@bradfitz가 맞습니다. @adg 가 제안한 솔루션은 내 모든 용도를 충족합니다.

이것은 흥미로운 주름입니다. 나는 현재 이것이 실패하는 것을 볼 수 있습니다.
GOPATH가 설정되지만 GOPATH에 여러 값이 포함된 경우
응용 프로그램이 하나의 시스템에 구축되어 배포되는 경우가 있습니다.
또 다른.

이 GOPATH 사용법을 무시하고 싶지 않습니다.
귀하의 응용 프로그램에 대한 지원 파일을 찾을 수 있지만
이 사용법이 얼마나 널리 퍼져 있고 현재
구현은 위에서 강조한 문제를 다룹니다.

2016년 9월 30일 금요일 08:35 Brendan Tracey [email protected] 은 다음과 같이 썼습니다.

@bradfitz https://github.com/bradfitz 가 맞습니다
@adg https://github.com/adg에서 제안한 모든 용도를 충족합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -250611813 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

나의 사용법은 정상적인 것이 아니다. 나는 과학적 연구를 하고 있으며 gopath/src 및 gopath/bin 뿐만 아니라 gopath/data 및 gopath/results 도 있는 것이 매우 효과적이라는 것을 발견했습니다. 따라서 결과 파일(기가바이트)을 복사하지 않고도 소스 파일을 새 시스템으로 쉽게 복사할 수 있습니다. 새 시스템(예: 클러스터)은 새 결과 파일을 생성하고 나는 그 결과를 중앙 위치에 복사할 수 있습니다. 정말 쉬운 다음 말을하기의 gopath = os.Getenv("GOPATH") 하고 파일 저장과 같은 뭔가 filepath.Join(gopath, "results", "projectname", result.json) .

감사합니다. 분명히 말씀드리자면 귀하의 사용법이 잘못되었거나
잘못, 나는 단지 GOPATH wrt의 이 사용법을 이해하고 싶었습니다.
내가 강조한 제약 조건.

2016년 9월 30일 금요일 09:09 Brendan Tracey [email protected]에서 다음과 같이 썼습니다.

나의 사용법은 정상적인 것이 아니다. 나는 과학적 연구를 하고 발견한
gopath/src와 gopath/bin 뿐만 아니라
gopath/data 및 gopath/results. 이렇게 하면 소스를 쉽게 복사할 수 있습니다.
(기가바이트)를 복사할 필요 없이 새 시스템으로 파일을
결과 파일. 새 시스템(예: 클러스터)은 새 결과 파일을 생성합니다.
그 결과를 중앙 위치에 복사할 수 있습니다. 정말 쉽습니다
그런 다음 gopath = os.Getenv("GOPATH")라고 말하고 filepath.Join(gopath,
"결과", "프로젝트 이름", result.json).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -250617618 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

현재 GOPATH=$HOME/.go 사용 중이라면 여기를 추천합니다.

@davecheney 는 공격을

이 토론에서 지원 파일을 찾기 위해 GOPATH 사용을 남겨두도록 합시다.

(GOPATH는 런타임 설정이 아닌 컴파일 시간 설정을 의미합니다. 사람들이 때때로 이를 흐리게 처리하고 GOPATH를 사용하여 런타임에 관련 파일을 찾는 것을 알고 있지만, 그렇게 하거나 일반적으로 지원 파일에 대한 더 나은 스토리가 필요하지만 이는 별도의 문제여야 합니다.)

런타임 시 관련 파일 찾기 관련: #12773

다시 한 번 @rsc 토론을 @randall77 , #12773 이 문제를 직접 해결하는 것보다 사용하기가 더 어렵습니다. 파일이 필요한(또는 파일을 저장하기 위해) 특정 코드는 많이 이동할 수 있으며, 입력/출력이 리팩토링과 독립적으로(그리고 별도로) 유지되는 고정된 위치를 원합니다.

이 문제는 GOPATH의 가능한 기본값에 관한 것입니다. GOPATH의 대체 사용에 대한 것은 _아닙니다_.

이 변경의 대상 사용자가 방금 변경하려는 사용자인 경우
Go로 작성된 새 프로그램을 설치하고 실제로 설치하려는 프로그램이 아닌
Go를 작성하고 다음의 사용자별 디렉토리에서 go get 복제를 수행하도록 하는 것은 어떻습니까?
$TMPDIR이고 $GOPATH가 설정되지 않은 경우 바이너리를 $PWD에 두시겠습니까? (확실히
이것은 go get import.path/for/a/command에 대해서만 의미가 있습니다. 그렇지 않은 경우
명령, $GOPATH가 설정되지 않으면 go get이 실패해야 함)

외부인에게는 wget 파일과 마찬가지로 매우 의미가 있습니다.

사용자가 Go 코드 작성을 시작하려면 설정 방법을 배워야 합니다.
제대로 GOPATH.

때때로 루트 권한이 없고 홈 디렉토리 아래에 Go를 설치해야 하기 때문에 저는 $HOME/go에 반대합니다. 그런 경우에는 $HOME/go가 GOROOT에 가장 적합할 것이라고 생각합니다.

Linux 시스템을 사용하는 경우 $HOME/.local의 목적을 해석하는 방법에 따라 $GOROOT의 가장 좋은 위치는 $HOME/go가 아니라 $HOME/.local/opt/go일 수 있습니다. , $HOME/.local/share(/usr/local/share 미러로 표시됨)만 XDG 기본 디렉토리 사양( https://standards.freedesktop.org/basedir-spec/basedir-spec-latest )에 정의되어

GOPATH / GOBIN(Linux에서)에 대한 최상의 기본값은 다음과 같아야 한다고 주장할 수도 있습니다.
GOPATH=$XDG_DATA_HOME/go 또는 $HOME/.local/share/go
고빈=$HOME/.local/bin

그러나 그것은 아마도 새로운 사용자에게 가장 이해하기 쉽지 않을 것입니다. 또한 Windows에서 가장 좋은 접근 방식이 무엇인지도 불분명합니다. $HOME/go 및 $USERPROFILE/go는 실용적으로 보입니다.

제발, _제발_ 이 스레드가 정식 Linux 경로 이름과 저장 위치에 대한 논의로 바뀌지 않도록 합시다. 그것은 생산적이지 않으며, 이 논의가 이미 Dave Cheney의 원래 게시물에서 상당히 벗어났다고 생각합니다.

또한 실제 절대 위치가 그렇게 중요한지 잘 모르겠습니다. 이 스레드에서 정말로 결정해야 하는 것은 "기본 Gopath를 원합니까?"입니다. (어느 정도 압도적인 예인 것처럼 들립니다.) 그리고 "시스템 전체에서 공유되어야 하는지 아니면 사용자에게 로컬로 공유되어야 하는지"(지금까지 대부분의 논의는 로컬에 관한 것이었습니다). 그 후에 구현하는 사람은 $HOME/gocode 또는 $HOME/go 또는 /usr/share/go/ 또는 PR을 검토하는 사람에게 합리적으로 보이는 원하는 것을 선택할 수 있으며 상황은 계속해서 꽤 괜찮을 것입니다.

시스템 전체의 GOPATH는 권한 문제로 인해 비스타터라고 생각합니다.

시스템 전체 경로는 좋든 나쁘든 GOROOT입니다.
데비안이 "시스템 전체" 패키지를 설치하는 데 사용하는 것처럼
더 나쁜.

시스템 전체의 GOPATH는 이 제안의 범위를 벗어납니다.
로그인한 사용자의 값에서 파생된 경로를 권장합니다.

2016년 10월 4일 화요일 08:52 Andrew Gerrand [email protected]이 다음과 같이 썼습니다.

시스템 전체의 GOPATH는 권한 문제로 인해 비스타터라고 생각합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -251238251 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

제발, 이 스레드가 정식 Linux 경로 이름과 저장 위치에 대한 논의로 바뀌지 않도록 하십시오. 생산적이지 않다

좋아, 하지 말자. 내 요점은 $HOME/go가 GOPATH 기본값으로 문제가 되지 않을 수 있다는 또 다른 이유를 지적하는 것입니다. 왜냐하면 이것이 Go(GOROOT라고도 함)의 로컬 사용자 설치를 위한 가장 "관용적인 Linux" 경로가 아닐 수 있기 때문입니다.

그 외에는 기본 GOPATH에 XDG_CACHE_HOME을 사용하는 것에 대해 논의한 적이 있다고 생각합니다. 이것이 제가 XDG_DATA_HOME을 언급한 이유입니다. 링크된 문서의 작성자가 어떤 역할을 하는지 또는 그것이 얼마나 "공식적인" 역할을 하는지는 모르지만 .

$집/직장.......

@adg @quentinmit @rsc 이 제안의 다음 단계는 무엇입니까?

이곳에서 어떤 일이 일어나는지 정말 보고 싶습니다. 제 수업에서 자주 발생하는 문제입니다. 어떤 기본값(심지어 내가 동의하지 않는 $home/go라도 :))이 없는 것보다 낫습니다.

$HOME/go 됩니다. 단 하나의 최선의 답은 없지만 이것은 짧고 달콤하며 $HOME/go가 이미 존재하는 경우 해당 이름을 선택하는 것이 문제일 수 있습니다. 이는 이미 go를 설치하고 GOPATH를 이해할 전문가에게만 만족할 것입니다.

누가 그 일을 하고 싶습니까?

이 작업을 하게 되어 매우 기쁩니다.

@campoy , 할 수 있어요 <= 이번 금요일?

저는 그렇게 말하고 싶습니다. 예 @bradfitz . 많은 양의 코드를 수행해야 할 것 같지는 않습니다.
내일 시작할 수 있어요.

업데이트: 나는 이것을 간단히 살펴보고 이미 몇 가지 코드를 작성했으며 몇 가지 테스트를 추가하고 오늘 나중에 변경 사항을 보낼 것입니다.

멋지다 얘들아! 👍

@ropike #

다음과 같은 이유로 Go 설치 디렉토리와 작업 공간 디렉토리의 이름을 동일하게 하는 것은 좋은 생각이 아닙니다. 예: go :

1) 사용자가 홈 디렉토리에서 tar -xzf go$VERSION.$OS-$ARCH.tar.gz 를 수행하면 순진한 사용자가 작업 공간을 손상/오염시키기가 매우 쉽습니다.

2) /usr/local 에 설치하지 않을 때(루트로 설치하고 싶지 않음) 새 사용자의 기본 환경은 다음과 같은 흐름이므로 원활하지 않습니다.
go$VERSION.$OS-$ARCH.tar.gz 다운로드
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> $HOME/go에 설치
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> 던짐 cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas GOROOT=$HOME/go 이면 GOROOT 와 GOPATH 가 같을 수 없기 때문에 이 기본값이 발생하지 않거나 go 오류가 발생한다는 것을 이해합니다. 이러한 경우에 앞서 말했듯이 사용자는 자신만의 GOPATH 를 설정할 수 있을 것으로 예상됩니다.

@mvdan 맞습니다. 설치를 위해 루트 권한을 사용하고 싶지 않은(따라서 ~/go에 Go를 설치할 가능성이 높은) 새 사용자를 위해 명시적으로 해야 하므로 작업을 시작하고 실행하는 것을 더 쉽게 만들지 않습니다. GOPATH를 다른 것으로 설정하십시오. 기본 GOPATH가 ~/gopath 또는 ~/gocode인 경우 쉽게 수정할 수 있습니다.

루트가 아닌 설치의 경우 새 사용자가 기본 GOPATH=~/go를 사용해야 하는 경우 사용자에게 tar -C 옵션을 사용하여 설치하지 않도록 명시적으로 요청하여 설치 문서를 약간 더 복잡하게 만들어야 합니다. ~/go

@rasky 저는 #

@krishnasrinivas에 동의합니다. 저는 루트 권한이 없었기 때문에 그냥 $HOME/go로 이동했습니다. 내 $GOPATH=$HOME/gowork도 설정했습니다.

@krishnasrinivas @joegrasse 완벽한 솔루션은 없습니다. GOPATH 직접 설정하는 것은 쉽고 대부분의 사람들이 그렇게 할 것으로 예상합니다. 여기서 문제는 바둑을 처음 접하는 사람들을 위해 우리가 무엇을 해야 하는가 하는 것입니다. 이들은 일반적으로 사용자 지정 위치에 자신의 Go 배포판을 설치하는 사람들이 아닙니다. 사용자 지정 위치에 Go를 설치하는 방법을 알 수 있는 사람은 GOPATH 설정 방법을 알 수 있습니다.

사전 설치된 Go 배포판을 사용하는 새로운 프로그래머 클래스 대신 생각하십시오. 우리는 그들이 Go 코드 작성을 시작할 수 있기를 바랍니다. 우리는 첫 번째 단계가 "이것이 환경 변수입니다. 이것이 환경 변수를 설정하는 방법입니다. 이제 GOPATH 를 이것으로 설정하십시오."가 되는 것을 원하지 않습니다. 이러한 단계는 Go와 관련이 없습니다.

다시 말하지만 완벽한 솔루션은 없지만 무언가를 선택하는 것이 현명해 보입니다.

@ianlancetaylor 나는 무언가를 선택해야한다는 데 완전히 동의합니다. 나는 단지 $HOME/go를 기본으로 하는 ./go로 가는 것이 최선의 선택이 아닐 수 있다고 믿습니다.

@ianlancetaylor GOPATH=$HOME/gopath는 앞서 언급한 이유로 인해 GOPATH=$HOME/go보다 더 나은 기본값입니다.

현재 이름이 문제라고 생각하지 않습니다. homedir 아래의 사용자 지정 go/bin 위치에 대해 PATH를 설정하는 방법을 알고 있다면 GOPATH를 설정하는 방법을 알고 있을 것입니다.

@joegrasse @krishnasrinivas " 사용자 지정 위치에 설치 "를 살펴보십시오.

/usr/local/go 이외의 다른 곳으로 압축을 풀고 있다면 -- 권한 등의 이유로 -- GOROOT도 설정하거나 소스에서 컴파일해야 합니다.

이 경우 제안된 $HOME/go보다 $HOME/gopath 등을 사용해도 아무런 이점이 없습니다.

새 사용자는 tar.gz에서 설치하는 것을 선호한다고 가정합니다. 나는 아니오를 인용 할 수 있습니다
숫자이지만 대답은 Linux 설치를 기반으로 한다고 생각합니다.
go에서 세 번째로 인기 있는 설치 대상입니다.

2016년 10월 25일 화요일 20:28 Krishna Srinivas [email protected]
썼다:

@mvdan https://github.com/mvdan 정확함, 원하지 않는 사용자를 위해
설치를 위해 루트 권한을 사용하십시오(따라서 설치 가능성이 높음).
Go in ~/go) 우리는 다음과 같이 일을 시작하고 실행하는 것을 더 쉽게 만들지 않습니다.
그들은 명시적으로 GOPATH를 다른 것으로 설정해야 합니다. 이것은 될 수있다
GOPATH가 ~/gopath 또는 ~/gocode이면 쉽게 수정됩니다.

루트가 아닌 설치의 경우 새 사용자가 기본값을 사용해야 하는 경우
GOPATH=~/go 그러면 문서가 약간 더 복잡해집니다.
사용자에게 다음 위치에 설치하지 않도록 tar -C 옵션을 사용하도록 명시적으로 요청함으로써
~/가다

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -255984498 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

문서도 모두 업데이트해야 합니다. 그것이 아마도 작업의 대부분일 것입니다.

2016년 10월 25일 10:14 Francesc Campoy 알림 @github.com
썼다:

네, 그렇습니다. 많은 양의 코드를 수행해야 할 것 같지는 않습니다.
내일 시작할 수 있어요.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -255892314 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

네, 그렇습니다. 많은 양의 코드를 수행해야 할 것 같지는 않습니다.
내일 시작할 수 있어요.

2016년 10월 24일 월요일 오후 4:05 Brad Fitzpatrick [email protected]
썼다:

@campoy https://github.com/campoy , 이번 주 금요일 <= 전에 할 수 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -255890668 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

필요한 경우 문서를 도와드릴 수 있습니다. 유일한 문제는 현재 자료가 기준점으로 GOPATH에만 의존한다는 것입니다. 예를 들어,

"또는 PATH 에 $GOPATH/bin 를 추가했으므로 바이너리 이름을 입력하세요."

또는

"GOPATH 아래에 패키지 생성, mkdir -p $GOPATH/src/github.com/user/hello"

GOPATH에 참여하고 그것이 무엇인지 배우지 않고는 Go에서 타사 패키지를 가져오는 것 외에 다른 작업을 수행하는 것이 거의 불가능합니다. go env 를 통해 기본 경로를 보고할 수 있다면 문서에서 쉽게 참조할 수 있습니다.

대신 $HOME/go/...를 대체할 수 있습니까(또는 Windows에서 이에 상응하는 항목)?

$HOME/go/bin 를 PATH에 추가했으므로(또는 GOPATH가 설정된 경우 $GOPATH/bin )...

아마도 문서에서는 개인이 PATH 환경 변수를 설정할 뿐만 아니라 GOPATH를 $HOME/go로 설정해야 한다고 예상할 수 있습니다. 중복되지만 나중에 GOPATH에 대한 참조를 위해 사용자를 준비합니다.

초기 문서는 기본값을 가정하고 환경 변수를 전혀 언급하지 않을 수 있습니다.

새 사용자는 tar.gz에서 설치하는 것을 선호한다고 가정합니다. 나는 아니오를 인용 할 수 있습니다
숫자이지만 대답은 Linux 설치를 기반으로 한다고 생각합니다.
go에서 세 번째로 인기 있는 설치 대상입니다.

내 의견은 Linux 설치에 편향되어 있습니다. /usr/local에 go를 설치하는 새 사용자의 경우 ~/go가 ~/gopath보다 인식하기 쉬운 디렉토리 이름일 수 있음을 알 수 있습니다.

초기 문서는 기본값을 가정하고 언급하지 않을 수 있습니다.
전혀 환경 변수?

예, GOPATH 설정에 대한 모든 혼란스러운 토론이 이동되기를 바랍니다.
설치 문서의 부록에, 우리가 GOROOT을 위해 하는 것처럼요.
현재.

2016년 10월 26일 수요일 06:01 Nathan Youngman [email protected]에서 다음과 같이 썼습니다.

아마도 $HOME/go/...가 대신 대체될 수 있습니다(또는
윈도우)?

$HOME/go/bin을 PATH에 추가했기 때문에(또는 GOPATH가 다음과 같은 경우 $GOPATH/bin
세트)...

아마도 어느 시점에서 문서는 개인이
PATH 환경 변수만 설정하고 GOPATH도 $HOME/go로 설정합니다.
중복되지만 이후 문서를 명확하게 만듭니다.

초기 문서는 환경을 언급하지 않고 기본값을 가정할 수 있습니다.
전혀 변수?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256142424 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

초기 문서는 기본값을 가정하고 환경 변수를 전혀 언급하지 않을 수 있습니다.

SGTM

Go 사용자에는 두 가지 유형이 있습니다.

• 기존 패키지를 바로 가져오는 사용자
• Go 개발자인 사용자

기본 GOPATH는 첫 번째 그룹의 대소문자를 수정합니다. 개발자용 문서에 대해 GOPATH 관련 지침을 계속 유지할 수 있습니다. 설치 시 더 이상 GOPATH 설정을 언급할 필요가 없습니다. 그렇지 않으면 @davecheney가 언급한 것처럼 부록이 있을 수 있습니다.

Go 때문에 ~/bin/go의 이름을 바꿔야 했던 사람으로서, 기본값이 무엇이든 간에 이미 존재하는 경우 실제로 Go의 ~/go임을 나타내기 위해 .dotfile이 있어야 한다고 제안하고 싶습니다. ~/go가 존재하지 않을 때 go는 그것을 생성하고 .dotfile을 만들고 향후 실행에서 찾을 수 있습니다. GOPATH를 ~/go로 명시적으로 설정하면 기본값이 사용되지 않으므로 .dotfile이 필요하지 않습니다.

도트파일이 존재합니다. $HOME/go 내부의 src/ 디렉토리입니다.

2016년 10월 26일 수요일 07:59 RalphCorderoy [email protected]에서 다음과 같이 썼습니다.

Go 때문에 ~/bin/go의 이름을 바꿔야 했던 사람으로서, 저는 제안하고 싶습니다.
기본값이 무엇이든 간에 이미 존재하는 경우
.dotfile이 실제로 Go의 ~/go임을 나타냅니다. ~/go가 존재하지 않을 때,
go는 그것을 만들고, .dotfile을 만들 수 있고, 이후 실행은 그것을 찾을 수 있습니다. 만약 내가
명시적으로 GOPATH를 ~/go로 설정하면 no .dotfile이 필요하지 않습니다.
기본값을 사용 중입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256173981 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

CL https://golang.org/cl/32019에 이 문제가 언급되어 있습니다.

일부 프로그래머는 환경 변수를 인식하지 못하더라도
최소한 _변수_에 익숙해야 합니다. 우리가 필요할 것 같아
문서에서 작업 공간의 위치를 ​​설명하기 위해 무언가를 사용하고,
$GOPATH 문자열도 마찬가지입니다.

2016년 10월 26일 06:24 Jaana Burcu Dogan 알림 @github.com
썼다:

초기 문서는 환경을 언급하지 않고 기본값을 가정할 수 있습니다.
전혀 변수.

SGTM

Go 사용자에는 두 가지 유형이 있습니다.

• 기존 패키지를 바로 가져오는 사용자
• Go 개발자인 사용자

기본 GOPATH는 첫 번째 그룹의 대소문자를 수정합니다. 우리는 여전히 유지할 수 있습니다
개발자용 문서에 대한 GOPATH 관련 지침. NS
설치는 더 이상 GOPATH 설정을 언급할 필요가 없습니다.
@davecheney https://github.com/davecheney 와 같은 부록을 가질 수 있습니다.
언급.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256149104 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

감사합니다. 원래 제안을 참조하십시오.

사실상 우리는 "go get이 소스를 폴더에 다운로드할 것입니다"라고 말할 수 있습니다.
홈 디렉토리 내에서 go/src/github.com/Foo/Bar라고 합니다."

2016년 10월 26일 수요일 06:01 Nathan Youngman [email protected]에서 다음과 같이 썼습니다.

아마도 $HOME/go/...가 대신 대체될 수 있습니다(또는
윈도우)?

$HOME/go/bin을 PATH에 추가했기 때문에(또는 GOPATH가 다음과 같은 경우 $GOPATH/bin
세트)...

아마도 어느 시점에서 문서는 개인이
PATH 환경 변수만 설정하고 GOPATH도 $HOME/go로 설정합니다.
중복되지만 이후 문서를 명확하게 만듭니다.

초기 문서는 환경을 언급하지 않고 기본값을 가정할 수 있습니다.
전혀 변수?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256142424 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

이것은 Hacktoberfest 의 마지막 주에 큰 문제가 될 것입니다

도트파일이 존재합니다. $HOME/go 내부의 src/ 디렉토리입니다.

"src"는 "이것은 Go에 의해 기본 GOPATH로 생성되었습니다" 도트 파일이 되는 일반적인 방법입니다.

방지하려는 것은 무엇입니까?

2016년 10월 26일 수요일 오전 9시 20분, RalphCorderoy [email protected]
썼다:

도트파일이 존재합니다. $HOME/go 내부의 src/ 디렉토리입니다.

"src"는 "이것은 기본 GOPATH로 생성되었습니다.
이동" 도트파일.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256194536 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$HOME/go 됩니다.

Windows 사용자를 위한 기능은 무엇입니까?

알렉스

Windows 사용자는 여기에서 Docker와 동일한 %USERPROFILE%\go 합니다 .

@davecheney , 2시간 전에 말한 것을 방지하려고 합니다. https://github.com/golang/go/issues/17262#issuecomment -256173981

가라는 말이 유행어입니다. 나는 ~/bin/go를 가지고 있었다. 사람들은 바둑을 하고 바둑과 관련된 소스 코드를 가지고 있습니다. Nabbing ~/go는 src가 포함되어 있기 때문에 이미 존재하는 경우 기본적으로 무례합니다. ~/go가 존재하지 않으면 Go는 이름을 검색하고 디렉토리를 생성하고 golang.org 도메인 이름을 기반으로 하는 중요한 dotfile을 사용하여 golang으로 스탬프를 찍을 수 있습니다.

그것이 문제이고 가능한 해결책입니다. 솔루션이 옳지 않다고 해서 문제가 존재하지 않는 것은 아닙니다.

나는 $ HOME/그룹에 투표한다

감사 해요.

GOPATH 기본값을 ~/.gosrc 로 사용할 수 있습니까?

GOPATH 기본값을 ~/.gosrc 로 사용할 수 있습니까?

Linux 및 OS X에서는 기본적으로 숨겨져 있고 Windows에서는 볼 수 있습니다. GOPATH를 숨기는 동기는 무엇입니까?

디폴트 값에 대한 논의는 한 달 전에 진행되었습니다. $HOME/go 에 대한 결정이 완료되었으며 이미 구현 중입니다. 그 주제로 돌아가면 스레드가 참을 수 없을 정도로 길어질 것입니다.

사람들은 바둑을 하고 바둑과 관련된 소스 코드를 가지고 있습니다.

나는 정말로 당신을 따르고 있지는 않지만 당신이 GOPATH를
이미 다른 것, 당신에게 영향이 없을 것입니다.

2016년 10월 26일 수요일 오전 9시 43분, RalphCorderoy [email protected]
썼다:

@davecheney https://github.com/davecheney , 나는 내가하는 일을 방지하려고 노력하고 있습니다.
두 시간 전에 말했다: #17262 (댓글)
https://github.com/golang/go/issues/17262#issuecomment -256173981

가라는 말이 유행어입니다. 나는 ~/bin/go를 가지고 있었다. 사람들은 바둑을 하고 소스 코드를 가지고 있습니다.
바둑을 하는 것과 관련이 있습니다. Nabbing ~/go가 이미 존재하는 경우 기본적으로
src가 포함되어 있기 때문에 무례합니다. ~/go가 없으면 Go
이름을 검색하고 디렉토리를 만들고 golang으로 스탬프를 찍을 수 있습니다.
중요한 dotfile(예: golang.org 도메인 이름 기반).

그것이 문제이고 가능한 해결책입니다. 솔루션이 되더라도
문제가 존재하지 않는다는 의미는 아닙니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256199766 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

@davecheney 님 , 이 문제는 ~/gocode를 제안하면서 시작되었습니다. 시간이 지나면서 ~/go가 되었습니다. @ropike 는 위에서 "$HOME/go가 이미 존재하는 경우 해당 이름을 선택하는 것이 문제일 수 있습니다. 이는 이미 go를 설치하고 GOPATH를 이해하는 전문가에게만 만족할 것입니다." 너무 오랫동안 골랑에 둘러싸여 있으면 "go"라는 단어가 얼마나 흔한지, 그리고 보드 게임과 같은 다른 의미가 있다는 것을 집단적으로 잊어 버리는 것 같습니다.

이 변경 사항은 바둑을 처음 접하는 사람들을 대상으로 하며 그들 중 일부는 바둑이 아닌 용도로 이미 ~/go를 가질 수 있습니다. go가 따라오고 GOPATH가 설정되지 않았으며 ~/go가 존재하지 않으면 생성하여 이름을 잡을 수 있다고 제안합니다. 그러나 ~/go가 존재하는 경우 이전 GOPATH 없는 호출에서 생성했다고 말할 수 있는 경우에만 사용해야 합니다. 이 플래그로 dotfile을 생성할 것을 제안했습니다. 당신은 ~/go/src가 그 플래그로 사용될 것이라고 말했습니다. 내 반대는 src 자체가 프로그래머, 즉 Go를 설치할 수 있는 프로그래머들 사이에서 드문 일이 아니라는 것입니다. ~/go/.default-gopath와 같은 특이한 dotfile은 이러한 잠재적 충돌을 방지합니다.

Go에 대해 ~/go를 수동으로 만들고 GOPATH 없이 go를 실행하면 dotfile이 없기 때문에 ~/go를 사용하지 않습니다. Go 설치 설정을 시작하여 계속 진행해야 하고 GOPATH를 설정하기 때문에 이것이 괜찮다고 생각합니다. 대상이 되는 단순한 "패키지 설치, go(1) 실행" 사례가 아닙니다.

이 중 어느 것도 문제로 간주되지 않는다면 괜찮습니다. 그러나 당신이 내 요점을 이해하지 못한다고 불평하는 한, 나는 그것을 계속 설명하려고 시도할 운명입니다.

이것이 내가 원래 다른 경로를 제안한 이유입니다. Rob의 제안으로 이제 공식적으로 제 손에서 벗어났습니다.

그렇긴 하지만 _a_ 경로가 선택되어 운동의 요점으로 볼 수 있어 기쁩니다.

귀하의 우려 사항에 대해 말씀드리자면 https://go-review.googlesource.com/#/c/32019/ 를 팔로우하여 귀하가 우려하는 문제가 정확히 논의되고 있는 곳을 방문

@RalphCorderoy , 보드 게임 해킹을 위한 ~/go 디렉토리가 있는 보드게임 프로그래머가 걱정

Rob과 Russ는 도트 파일에 매우 적합합니다. 답변에 도트 파일(또는 심볼릭 링크)이 포함된 경우 답변을 명시하는 것보다 문제를 명시하는 것이 좋습니다.

@bradfitz , 예, ~/go는 이미 gogame 플레이어를 위해 존재하며, 추가로 ~/go/src는 프로그래머 gogame 플레이어이기 때문에 존재합니다. 그렇지 않으면 Go를 가지고 놀지 않을 것입니다. (나는 ~/chess/src를 가지고 있다.)

adg의 요약 논리 https://go-review.googlesource.com/c/32019/#message -09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c 괜찮아 보이고 ~/go 만약 존재하지 않는다면 test -d ~/go/src 하지만

~/go가 아니라 Dave의 원래 제안과 같이 더 특이한 것이라면 문제가 되지 않습니다. ~/go가 매우 인기가 있음을 보여 주는 현재 사용되는 설문조사는 유권자가 이슈와 소셜 미디어를 팔로우할 만큼 열심인 Go 프로그래머일 때 그다지 도움이 되지 않는다고 생각합니다.

@RalphCorderoy CL 32019에 엔지니어링된 이중 속옷의 양은 버전 1.8 이전에 Go를 _사용하지 않고_ 설정하지 않은_ 소수의 게임 프로그래머가 잠재적인 불편을 겪을 수 있는 정도면 충분하다고 생각합니다. GOPATH _and_도 언어인 바둑을 배우기 시작했습니다.

go 도구는 go가 아닌 코드를 삭제하거나 손상시키지 않을 것입니다. _몇 가지_ 상황에서 약간 혼란스러운 메시지를 받게 될 것입니다. 이것을 설명하기 위해 go 도구는 $GOPATH/src 의 맨 위에 Go 소스를 빌드하지 않습니다. 왜냐하면 해당 코드는 가져올 수 있는 패키지 내에 있지 않기 때문입니다. 또한이 변화의 다른 목적은 쉽게에 확인하는 것입니다 go get , 그래서에서 게임 수준의 이동 소스 코드가 있었다 _if_에 다운로드 소스에 기본 위치를 제공하여 몇 가지 코드 ~/go/src , go gettable 리포지토리에서 파생된 하위 디렉터리와 충돌할 가능성은 매우 희박하며, 그런 일이 발생하더라도 데이터가 변경되기 전에 go 도구나 git이 엉망이 될 것입니다.

나는 당신이 우려하는 상황이 매우 가능성이 희박하다고 생각하며 위의 설명으로 더욱 완화되었습니다.

( GOPATH=$HOME 에 대한 유효한 주장일 뿐입니다): goimports 의 성능이 해결되었습니까? .goimport_ignore 파일에 대해 기억합니다. 그렇지 않으면 인기 있는 편집자의 성능이 저하될 수 있습니다.

따라서 GOPATH!=$HOME 는 충돌이 없고 오염되지 않은 옵션일 가능성이 높으며 성능이 있어야 합니다.

@davecheney go get 이후에는 ~/go/{bin,src,pkg}에서 지울 쓰레기가 생겼고 인터넷에서 찾은 줄을 붙여넣는 것은 Go에 대한 좋은 소개가 아닙니다.

@RalphCorderoy 이 변경의 목표는 새로운 Go 사용자가 더 쉽게 사용할 수 있도록 하는 것이라는 점을

@RalphCorderoy 당신이 설명하는 상황은 드물며 임의의 웹사이트에서 셸 명령을 실행하는 사람은 디스크가 뒤섞는 것은 고사 합니다. (편집: Wine이 사용자의 홈 디렉토리에서 .wine 를 자동 생성하고 수정하는 것을 고려하십시오. 사용자가 거기에 다른 것을 가지고 있다면 어떻게 될까요? 결국 "와인"은 특정 음료에 대해 사용하는 용어입니다.)

"바둑" 언어와 "바둑" 보드 게임 사이의 이름 충돌은 확실히 이해되고 잘 알려져 있습니다. 파일 시스템은 공유 리소스이며 충돌이 발생하고 불가피합니다.

@davecheney , 저는 새로운 Go 사용자가 아니기 때문에 이 변경 사항이 저를 돕기 위한 것이 아니라고 말하지 말아주세요. 나는 당신이 그것을 지적하기 시작하기 전부터 항상 알고 있었습니다. 나는 또한 당신의 위치가 len(intersect(existing-~/go, GOPATH-less))이 너무 작아서 걱정할 수 없다는 것을 이해합니다.

~/go에서 go-get spew를 정리한 후 일반적으로 거기에 없는 것이 무엇인지 알고 있었기 때문에 명령이 $HOME 아래에서 더 많은 경우에 수행했을 수 있는 다른 작업을 조사해야 합니다. 청소가 필요했습니다.

구독 취소

기분 나쁘게 했다면 죄송합니다. 더 이상 대응하고 싶지 않습니다
이 문제에 대해 당신과 함께. 감사합니다.

2016년 10월 28일 금요일 오전 3시 28분, RalphCorderoy [email protected]
썼다:

@davecheney https://github.com/davecheney , 이런 말 좀 그만해주세요
나는 새로운 Go 사용자가 아니기 때문에 변화는 나를 돕기 위한 것이 아닙니다. 나는 가지고있다
당신이 그것을 지적하기 시작하기 전에도 항상 그것을 알고 있었습니다. 나도
귀하의 위치가 len(intersect(existing-~/go, GOPATH-less))임을 이해하십시오.
걱정하기에는 너무 작습니다.

~/go에서 뿜어져 나오는 것을 정리한 후, 그가 무엇을 알고 있었는지
평소에는 거기에 없었고, 그는 다른 무엇을 보기 위해 조사해야 했습니다.
추가 정리가 필요한 경우 명령이 $HOME에서 수행되었을 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/golang/go/issues/17262#issuecomment -256697043 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney, 아니, 범죄가 아닙니다. 같은 땅을 계속 덮는 것은 의미가 없습니다.

$HOME 가 설정되지 않은 경우 예상되는 동작은 무엇인지 궁금합니다.

나는 그런 경우의 시스템에서 작업한 적이 없지만 누군가가 어떤 이유로 기본 환경 변수를 수정했을 가능성이 있는 것 같으며 이 극단적인 경우는 일관되게 처리되어야 합니다.

현재 $GOPATH='' ; 그것은 현재 작업 디렉토리를 사용한다는 것을 의미합니까?

현재 작업 디렉토리 사용

이것이 GOPATH를 설정하지 않은 새로운 Go 사용자에게 가장 유용할 수 있다는 생각이 들었습니다. go get 는 현재 디렉토리를 채우는 wget 등과 유사합니다. 그들은 이 시점에서 GOPATH의 경로 측면에 관심이 없으며, 자신이 만든 새로운 임시 디렉토리가 제공하는 것처럼 다른 온라인 항목을 가지고 노는 모든 모험을 분명히 원할 것입니다. 그들은 참조하는 다른 저장소를 얻고, 실행하고, 쉽게 삭제할 수 있습니다.

• GOPATH가 설정되지 않은 경우:
  
  
  
  • ~/{bin,pkg,src} 중 하나 또는 두 개만 존재하지만 전부는 아닌 경우:
  
  
  • 그들은 GOPATH를 설정해야합니다. pkg는 특이한 것입니다.
  
  
  • 그렇지 않으면 모두 또는 전혀 존재하지 않습니다.
  
  
  • 그것들이 모두 존재하는지 확인하십시오
  
  
  • 이동 경로=$(비밀번호)
  
  

나는 이것에 대해 엇갈린 감정을 가지고 있지만 $GOPATH 설정한 사람으로서 나의 지배적인 감정은 go get 행동이 "결정적"이어야 하고 항상 $GOPATH 아래에 설치해야 한다는 것입니다. 일관되고 잘 문서화된 목적지.

이 변경 사항에 영향을 받지는 않았지만 go get 명령이 실행될 때 작업 디렉터리가 무엇인지에 따라 다른 위치에 항목을 다운로드하는 것이 이상하게 느껴집니다. 이것이 wget , npm install 및 기타 도구가 하는 일이라는 것을 알고 있지만 일관된 $GOPATH 값(이것이 내가 이 변화의 정신을 해석함).

이것이 이 문제의 범위를 벗어나는 경우 $HOME 가 실제로 설정되지 않은 경우 단순히 종료하고 오류를 출력하는 것이 좋습니다.

나는 제3세계의 자바 세계에서 온 5명의 새로운 프로그래머를 가르쳤습니다. 그들은 모두 GOPATH에 대해 확실히 혼란스러워했습니다. 헉, 저도 Go 1이 나오기 전에 다시 시작할 때 그랬어요. 저는 개인적으로 "$HOME/gopath"를 사용하지만 "go get" 명령이 운영 체제에 대한 이동 경로를 만드는 방법에 대해 명확한 go 블로그를 가리키도록 제안합니다. 그게 우리에게 필요한 전부입니다. 사양이 아닌 "go get" 명령에 의한 몇 가지 지침. 하지만 빌어먹을 간단한 블로그 게시물!!

분명히 GOPATH가 설정되지 않은 경우를 의미합니다. 현재 표시되는 오류 메시지를 업데이트하기만 하면 됩니다. 채택률은 이미 올랐습니다.. 새내기들이 하고 있는 현재의 구글 잇업 방식이 아닌 약간의 도움이 필요합니다.

@einthusan https://golang.org/doc/code.html#GOPATH 에 꽤 잘 문서화되어 있는 것 같지만, Go를 시작하는 사람들이 실제로 이 페이지를 읽는지 모르겠습니다.

스팸 죄송합니다. 인터넷 검색을 한 후.. "GOPATH가 설정되지 않았습니다... 현재 작업 디렉토리를 임시 GOPATH로 사용하시겠습니까?"라는 메시지가 사용자에게 표시되어야 한다고 생각합니다. (예 아니오)

@einthusan , cmd/go가 대화식 프롬프트를 수행한 전례가 없습니다.

새 기본 GOPATH가 $HOME/go인 경우. 사람들은 이 https://hub.docker.com/_/golang/ 이 동일한 동작을 채택할 것으로 기대하지 않습니까?

@cescoferraro 그것은 해당 이미지의 유지 관리자에 대한 질문입니다. "공식"이라고 표시되어 있지만 해당 프로젝트는 Go와 관련이 없습니다.

unset $HOME 대한 내 질문에 답변/응답:

현재 구현(CL은 위에 링크됨)에서 $HOME 가 설정되지 않은 경우 $GOPATH 기본값은 "" $HOME 입니다. https://go-review.googlesource.com/#/ c/32019/11/src/go/build/build.go 이것이 현재 동작과 일치한다고 생각합니다.

$HOME 가 항상 일반 로그인 세션에서 설정되기 때문에 이 극단적인 경우는 거의 없을 것이라고 생각합니다. 이는 대부분의 Go 프로그래머의 경우일 것입니다. 나는 개인적으로 행동을 명시적으로 _좋아_ 하고 싶지만, "부작용"(작업 디렉토리에 설치하는 것과 같은)은 없는 것 같습니다. 틀 렸으면 고쳐줘. :)

Go를 처음 시작하는 사람들을 위해 이것이 현재 경로와 같도록 하십시오.

GOPATH=$(pwd)

export GOPATH=$(pwd) 하면 프로젝트 간에 쉽게 전환할 수 있습니다.

이 변경 사항에 대해 제안한 동작:

환경 변수

• GOPATH 가 설정되면 도구는 항상 그랬던 것처럼 작동합니다.
• 그렇지 않으면, 우리는 확인 HOME ( home plan9를 들어, USERPROFILE Windows 용) 환경 변수를.
  
  
  
  • 해당 환경 변수가 설정되지 않으면 GOPATH 도 설정되지 않습니다. 즉, "go get"이 cannot download, $GOPATH not set. 와 함께 실패합니다.
  
  

> unset GOPATH
> unset HOME
> go env GOPATH

• 그렇지 않으면 GOPATH 는 $HOME/go ( $home/go , %USERPROFILE%\go )로 설정됩니다.

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

GOPATH 생성

현재 $GOPATH 가 존재하지 않으면 go get import/path 실행할 때 생성됩니다. 이것은 변경되지 않습니다.

유일한 변경 사항은 $GOPATH 가 사용자 환경에서 설정되지 않은 경우(즉, echo $GOPATH에 값이 표시되지 않는 경우) 기본값이 허용 가능한지 확인하기 위해 추가 검사가 수행된다는 것입니다.

• GOPATH가 설정되지 않고 기본값이 생성되지 않은 경우: 명령이 실패합니다.

> 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'
👎

• 기본 $GOPATH 이 존재하지 않으면 디렉토리가 생성되었음을 설명하는 경고가 표시되며 추가 정보는 go help gopath 를 가리킵니다.

> 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
👍

• 기본 $GOPATH 가 있는 경우:
  
  
  
  • 그리고 이것은 디렉토리가 아닙니다: 명령은 실패할 것입니다(이전에 그랬던 것처럼)
  
  

> 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
👎

• 빈 디렉토리이거나 src 라는 하위 디렉토리가 있는 디렉토리는 명령이 성공합니다(경고 없음).

> 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
👍

• src 라는 하위 디렉토리가 없는 비어 있지 않은 디렉토리입니다. 명령이 실패합니다.

> 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
👎

따라서 기본 GOPATH 사용하여 디렉토리를 만들 때마다 새 경고만 포함됩니다.

@campoy 행동 제안이 멋지게 보입니다.

그러나 다시 고급 사용자로서 나는 우리 중 얼마나 많은 사람들이 $HOME/go 를 GOPATH 로 매일 진지하게 사용하는지 알고 싶습니다. 파이썬 작업 디렉토리에서 가상 환경을 시작하는 것과 유사하게 GOPATH 를 설정하는 go 명령이 있어야 한다고 생각했습니다.

여러 프로젝트에서 작업하기 때문에 일반적으로 다음과 같이 합니다.

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

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

@jinmatt
이 변경은 설정되지 않은 GOPATH에 대한 동작만 수정하며, 이는 변경 범위입니다.
커뮤니티는 이미 $HOME/go에 대한 합의에 도달했습니다.

$HOME/go 마음에 들지 않으면 GOPATH 를 원하는 값으로 설정하십시오(예: 제 경우에는 $HOME).

디자인 스케치 감사합니다.

1. 이제 GOPATH가 'go get' 중에만 생성될 것임을 확인했으므로 나머지 'go get -v' 동작과 일관되게 -v 플래그가 제공되는 경우에만 메시지를 인쇄해 보겠습니다.
2. 디렉토리가 생성된 경우 메시지는 최대

# 생성된 GOPATH=/users/campoy/go; gopath를 도우러 가십시오'를 참조하십시오

경고가 아닙니다. 경고가 잘못되었습니다. 반면에 만들기가 실패하면 인쇄하는 것이 좋습니다.

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

GOPATH가 유추되거나 명시적으로 설정되었는지 여부에 관계없이 두 메시지를 모두 인쇄할 수 있습니다.

1. 빈 디렉터리와 src 하위 디렉터리에 대한 경험적 방법은 너무 복잡합니다. 설상가상으로 그들은 가설적인 문제를 다루고 있으며 가설은 설계하기가 매우 어렵습니다. 더 간단하고 예측 가능한 행동을 하는 것이 좋습니다. 먼저 실제 문제의 구체적인 예가 있을 때까지 규칙을 두지 않는 것이 합리적이라고 생각합니다. 사람들이 베타 기간 동안 문제를 보고하고 후보를 출시할 시간이 있을 것입니다. GOPATH=$HOME/go를 설정합시다($HOME이 설정된 경우).

편집: Github 마크다운이 이것을 완전히 망치지 않았다고 가정하십시오.

@campoy src/ 디렉토리와 관련하여 GOPATH가 설정되었지만 src 디렉토리가 없을 때 go get 의 현재 동작은 무엇입니까? 만들지 않을 이유가 있습니까?

$HOME/go/src가 첫 번째 go get(또는 해당 환경 변수가 설정된 경우 $GOPATH/src)에서 생성되는지 설명하는 것이 더 간단해 보입니다.

오늘날에는 GOPATH가 설정되면 필요한 디렉토리가 필요에 따라 무조건 생성됩니다.

CL https://golang.org/cl/33356에 이 문제가 언급되어 있습니다.

CL https://golang.org/cl/33730에 이 문제가 언급되어 있습니다.