설명은 링크로 대체.

영문 오쏘 설명: https://github.com/golang/go/wiki/Modules

국문 사용자 설명: https://kimmachinegun.github.io/2018-08-25/go-modules-살펴보기

 

이번에 추가된 module로 인해서 할 수 있는게 더 생겼는데 예를 들면 Github 같은 VCS에서 branch(정확하게는 release) 또는 tag에 따라 버전 선택이 가능해졌다.

GOPATH와 무관하게 돌릴 수 있다는 점까지 더해서 쓰는 사람 입장에서는 확실히 편하게 쓸 수 있는 여지가 보인다.

 

패키지를 받아서 쓸 때는 아래와 같은 식으로 작업한다.

 

패키지 배포시에는 아래와 같이 한다.

1. 신규

 - 패키지 소스 작성 > Git 레포지터리 초기화(=master 등록) & 커밋 > master 푸시

2. 수정 및 업데이트

 - Git 분기(branch) 생성 > 분기로 체크아웃 > 분기 커밋 & 분기 게시(=푸시?)

 - Git master로 체크아웃 > 패키지 소스 수정 > master 커밋 & 푸시

3. (Major) 버전 업데이트

 - Git 분기(branch) 생성 > 분기로 체크아웃 > 분기 게시(=푸시?)

 - Git master로 체크아웃 > 패키지 소스 수정 및 go.mod 버전 표기 추가 > master 커밋 & 푸시

 

위 절차에서 소스 수정시마다 2, 3번 과정이 무한반복이라고 보면 되며, 패키지로 가져오려면 Release 또는 Tag 표기가 되어 있어야 한다.

개인적으로 tag는 쓰기가 너무 불편해서 Github이나 Bitbucket 같은 서비스를 쓸 경우 해당 서비스의 Release 기능을 활용하는게 좋을 것 같다.

모듈 예시: https://github.com/practice-golang/go111module-pkghello

 

"모듈 예시"를 땡겨오는 예시 - import 주석은 $GOPATH/src/{패키지 이름} 안에서 작업할 때는 안 넣어도 된다.

 - GO111MODULE=on 환경변수는 당연히 잡아줘야 한다.

 

 

위 예시대로 하면, hell이라는 이름의 패키지로 가져오게되는 최종 코드는 "Hello, this is 3.2.0"이 아닌, "Hello, this is 3.1.0"을 가져와서 출력하게 된다.

 

아래는 그냥 참고

* GOPATH 밖에서 쓰는게 기본이며, GOPATH안에서는 반드시 환경변수에서 GO111MODULE=on 설정을 선행해야 한다.

* 패키지 배포시 반드시 v1.2.3 - 이 규칙을 따라야 한다.

* 패키지 개발자는 소스 경로 뒤에 /v2, /v3 등의 꼬리표를 붙여서 Major version을 구분하고 Release/Tag로 Minor/Patch version을 세분화할 수 있다.

* 사용자는 위 경로 뒤에 Minor/Patch version을 이용하여 정확히 가져오려는 패키지 또는 모듈 버전을 지정할 수 있다.

* 예시대로 정확하게 하지 않으면 go.sum과 go.mod 내용에서 사용자가 받은 패키지의 버전 숫자가 제멋대로 v0.0.0 으로 바뀐다.

* Author 가 작성한 영문설명대로 Git 최신버전을 굳이 사용할 필요는 없다. - 작년 버전 동작 확인

* 버전이 0.x 대이거나 1.x 대일 경우 v0, v1은 넣지 말라고 한다. 그래서 위의 예시에서도 v0, v1과 v 빠진 부분은 받아지지 않을 것이다.

 - 이건 일관성이 없어 보이는데 나중에는 바뀔 거라 기대한다.

* 로컬패키지를 사용하는 예시로 따로 레포지터리를 만들어봤다.

* vscode, go extension

 - 자동완성 문제는 GOPATH, inferGopath, go mod vendor로 해결 가능하다. 베타8에서 해결된 것 같다. #1532에 관심을 갖자. 오쏘가 창구를 닫았다. 곧 정식 나올 것 같다. 으히히~

 

끝.