GOPATH에 의존하지 않는 Go 개발 환경(Go1.15 버전)

2018년 전 Go에 대한 불만은 다음과 같다.

$GOPATH/src 부하 하에서만 개발

임포트 패키지의 검색 목적지로 $GOPATH/src를 사용했기 때문이다.
어디선가 들려오는 패키지를 쓰려면$GOPATH/src 부하에 존재하지 않으면 검색이 불가능해 실질$GOPATH/src 부하에서만 개발할 수 있다는 것이다.
그러나 2018년 말 발표된 고 1.11은 이 불만을 해결할 것으로 보인다.
Go 1.11을 가져온 Go modules라는 새로운 메커니즘이 유효하면 GOPATH/src는 패키지 검색 목적지로 사용되지 않습니다.
대신 github.com/go-sql-driver/mysql의 패키지가 import의 경우github.com에서 존재 여부go-sql-driver/mysql와 같은 창고가 존재하는지 물어보면 존재하는 경우 자동으로 이런 행위를 하게 된다.
Go modules 자체의 설명은 이 기사의 주제가 아니기 때문에 다른 사람에게 양보했다.
Go modules는 이전의 문제를 해결했지만 Go 1.11의 환경 변수 GOPATH에 대한 의존도가 완전히 사라졌다고 오해했다.
이 글의 목적은 당시 나에게 Go modules 아래GOPATH에서 맡은 역할과 그 역할을 설명하고 가능한 한 GOPATH에서 제외하기 위한 것이다.

GOPATH가 맡은 역할.

GOPATH 아래에 존재하는 디렉터리는 다음과 같다.

src

bin

pkg/$GOOS_$GOARCH

pkg/mod

pkg/sumdb

src

$GOPATH/src 디렉토리에 Go의 소스 코드가 구성되어 있으며, 앞서 설명한 대로 Go modules가 비활성화된 상태(GOPATH mode라고 함)에서 디렉토리는 import package의 검색 대상으로 사용됩니다.
이 디렉토리에는 Go modules를 사용할 필요가 없습니다.
구체적으로 환경 변수GO111MODULE=on로 설정하면 $GOPATH/src에서 열립니다.

bin

$GOPATH/bin 디렉토리는 Go 명령으로 설치된 실행 파일을 구성하는 데 사용되는 디렉토리입니다.
환경 변수GOBIN를 사용하여 이 실행 파일을 구성하는 디렉토리를 수정할 수 있습니다.
따라서 ~/bin를 사용하려면 지정GOBIN=$HOME/bin을 통해 $GOPATH/bin에서 엽니다.

pkg/$GOOS_$GOARCH

$GOPATH/pkg/$GOOS_$GOARCH 디렉토리에 Go 명령으로 설치된 Binary-Only package가 구성됩니다.
Binary-Only package란 패키지의 컴파일링에 사용되지 않는 소스 코드를 2진법으로 나눠주는 구조다.
네.이렇게 쓰는 이유는 이 기능이 Go1.13부터 폐지되기 시작했기 때문이다.
나도 이 기능을 사용해 본 적이 없어서 자세한 상황을 모르겠다.
고1.13에서 폐지됐기 때문에 고1.13을 이용한 이후$GOPATH/pkg/$GOOS_$GOARCH부터 개방한다.
cf. Binary-Only Packages
cf. Go 1.13 Release Notes

pkg/mod

이 디렉토리는 Go modules가 활성화된 경우에만 사용할 수 있습니다.
Go modules가 유효하지 않은 상태(GOPATH mode)인 경우 다운로드한 패키지가 $GOPATH/src에 구성됩니다.
이에 비해 Go modules는 유효한 상태(module-aware mode라고 함)에서 다운로드한 패키지(정확히 module라고 함)가 $GOPATH/pkg/mod에 놓여 있다.
이 모듈에 대한 상담 결과의 캐시도 저장됩니다.go get명령 등은 이 카탈로그를 참조하지만 현금처리이기 때문에 있으면 사용하고 없으면 다운로드한다.
따라서 이 디렉터리에서 일해야 한다는 제약이 사라졌다.
또한 2010/09시 최신 Go1.15에 환경 변수GOMODCACHE가 준비되어 있어 위치를 변경할 수 있습니다.
따라서 ~/.cache/go_mod를 사용하려면 지정GOMODCACHE=$HOME/.cache/go_mod을 통해 $GOPATH/pkg/mod에서 엽니다.
cf. Go 1.15 Release Notes

pkg/gosum

Go 1.13은 Go module proxy와 Go checksum 데이터베이스 구조를 가져옵니다.
고모듈즈가 위탁창고에 의존하는 서비스와 악의적인 공격자가 모듈을 훔쳐 바꿀 수 있는 문제를 해결하기 위해 마련된 것이다.
이러한 세부 사항은 언급하지 않겠습니다. 여기서 주의해야 할 것은 go get 등에서module을 얻었을 때module proxy에 문의하여module의 정보를 얻고 checksum 데이터베이스에 문의하여module의 완전성을 확인하는 것입니다.pkg/gosum는 checksum 데이터베이스에 문의한 결과를 저장하는 캐시 디렉터리입니다.
module proxy에 문의한 결과의 캐시가 pkg/mod/cache 아래에 있기 때문에 이전 GOMODCACHE 환경 변수로 제어할 수 있습니다.
죄송합니다. Go 1.15 시점에는 이 디렉토리를 제어하는 방법이 없습니다.(내가 찾는 방법이 너무 달기만 하면 미안해.)
cf. Proposal: Secure the Public Go Module Ecosystem
cf. Issue: cmd/go: add GOMODCACHE

총결산

고 1.11에서 도입한 고 모더스는 고 개발을 pkg/gosum 밖에서도 할 수 있게 했다.
다만 $GOPATH/src 환경 변수인 패키지의 목적지 검색 기능은 사용되지 않고, 다른 용도인 고1.15도 현재 활용되고 있다.
아래 설정에 따라 GOPATH 이외의 $GOPATH/pkg/gosum 아래 디렉터리를 다른 위치로 이동할 수 있습니다.
지정한 목록은 제 취향에 따라 정해졌으니 여러분이 좋아하는 목록을 지정하세요.

export GO111MODULE=on # Go 1.11 から利用可能
export GOBIN=$HOME/bin
export GOMODCACHE=$HOME/.cache/go_mod # Go 1.15 から利用可能

앞으로Issue: cmd/go: default to GO111MODULE=on GOPATH mode$GOPATH 폐지가 논의되고 있다.
그러나 이 주석에서 말한 바와 같이 GO111MODULE=off 환경 변수 자체는 한동안 지속될 것이다.