Realize는 Go1.11의 Modules에서 사용할 수 없습니다.

지난해 [Go] Realize가 편하니까 좀 더 친해지려고 해요. 기사를 공개한 뒤 지금도 가끔 좋은 일을 할 수 있지만 열재장착 도구로 리얼즈가 정말 쓰기 좋아요.
※ 이럴 때'아니오, 이 도구가 좋아요'등이 있으면 꼭 댓글로 알려주세요. 울면서 기뻐할 거예요
그러나 Go1.11에서 내장된 모듈을 사용하려고 시도하면 realize를 실행할 수 없습니다.
이 기사는 이 원인을 찾기 위한 여행기다.

발생한 문제

realize init 명령을 클릭하여 .realize.yaml 라는 파일을 생성합니다.
이 파일을 기반으로 모니터링할 파일 범위를 좁히고 수정할 때 Before/After에서 실행할 명령을 지정하는 등 다양한 옵션을 지정할 수 있습니다.
예를 들면go의 파일을 변경하는 것을 감시할 때 다시 go run ...하려면 다음과 같이 설정하십시오 (부분 발췌).

...
schema:
  watcher:
    extensions:
    - go
  commands:
    run:
      status: true
...

그러나GO111MODULE=onrealize를 시작할 수 없습니다.

$ realize start
[09:38:37][MYAPP] : Watching 0 file/s 0 folder/s
[09:38:37][MYAPP] : Build started
[09:38:37][MYAPP] : Build
 exec: not started

내가 이 원인을 탐색할게.

문제 있어요?

Go module support

어쨌든, Gopkg.toml은 go입니다.mod와 go.sum으로 바꾸면?
그런 거 아니죠...

Cannot do --run with go1.11 using go mod under windows.

Windows뿐만 아니라 Mac/Linux도 발생했습니다.
다만, 근본적인 원인이 보이지 않아 코드를 직접 보기로 했다.

코드 읽기

realize.go

먼저 main 포장부터 읽으세요.
먼저 realize start 부분을 찾습니다.
CLI 패키지는 gopkg.in/urfave/cli.v2 를 사용하는 것 같습니다.

Commands: []*cli.Command{
    {
        Name:   "start",
        ...
        Action: start,
    },

개인 함수start를 불렀기 때문에 다음은 거기다.
많이 썼지만 마지막return r.Start() 앞에 있는 것 같아요.

cli.go

보기만 해도goroutine는 복수의 항목을 감시할 수 있을 것 같다.
여러 프로젝트를 뛰어넘는 개발은 원래 설정된 프로젝트의 경로를 설정할 수 있기 때문에 데이터 라이브러리에 포함되지 않을 수도 있다.realize.yaml.

// Start realize workflow
func (r *Realize) Start() error {
    if len(r.Schema.Projects) > 0 {
        var wg sync.WaitGroup
        wg.Add(len(r.Schema.Projects))
        for k := range r.Schema.Projects {
            r.Schema.Projects[k].exit = make(chan os.Signal, 1)
            signal.Notify(r.Schema.Projects[k].exit, os.Interrupt)
            r.Schema.Projects[k].parent = r
            go r.Schema.Projects[k].Watch(&wg)
        }
        wg.Wait()
    } else {
        return errors.New("there are no projects")
    }
    return nil
}

다음으로 우리는 r.Schema.Projects[k].Watch(&wg) 함수를 따를 것이다.

projects.go

// Watch a project
func (p *Project) Watch(wg *sync.WaitGroup) {
    ...
    // before start checks
    p.Before()
    // start watcher
    go p.Reload("", p.stop)
    ...

댓글 감사합니다.p.Before() 이 일대는 이상한 것 같다.

func (p *Project) Before() {
    ...
    if hasGoMod(Wdir()) {
        p.Tools.vgo = true
    }
    ...
    // setup go tools
    p.Tools.Setup()
    // global commands before
    p.cmd(p.stop, "before", true)
    // indexing files and dirs
    for _, dir := range p.Watcher.Paths {
        base, _ := filepath.Abs(p.Path)
    ...

hasGoMod(Wdir()) 중 p.Tools.vgo 이 진짜입니다.
고1.11이면 go mod ... 좋지 않나...?Wdir() 작업 디렉토리로 돌아갑니다.
그럼,hasGoMod()은요?

utils.go

func hasGoMod(dir string) bool {
    filename := path.Join(dir, "go.mod")
    if _, err := os.Stat(filename); os.IsNotExist(err) {
        return false
    }

    return true
}

하하.go.mod이 있다면vgo은 진짜가 된다.
그렇게 지도 모른다, 아마, 아마...

tools.go

있다.projects.go의Before()내Setup()에 다음과 같이 적혀 있다.

// Setup go tools
func (t *Tools) Setup() {
    var gocmd string
    if t.vgo {
        gocmd = "vgo"
    } else {
        gocmd = "go"
    }
    ...

    t.Install.name = "Install"
    t.Install.cmd = replace([]string{gocmd, "install"}, t.Install.Method)
    t.Install.Args = split([]string{}, t.Install.Args)
    ...

즉, Go Modules를 지원하지 않는 것 같습니다.

총결산

"어, 홍보 기회 아니야?"
"아니오, 원래 여기에 쓰면 홍보를 통해 합병되었다고 할 수 있습니다."
생각하시는 분도 계시죠?
하지만 Cannot do --run with go1.11 using go mod under windows.와 다른 몇몇 Issue를 본 사람들은 이미 파악했다. 며칠 전 논평에서
thanks for the support and for the reports, in the last months we had some company changes but in the first trimester 2019 we will release a new version
보고해 주셔서 감사합니다.2019년 1기에 새로운 버전이 출시됩니다.
이런 일.
1.12에서 GO111MODULE=on까지의 행동이 표준인 것 같다는 점에서 조금만 더 기다려도 될까요? 그래도 안 되면 다른 도구나 자제를 시도해 보세요.
명백히 잘못된 정보가 있다면 저에게 댓글을 달아주시면 좋겠습니다.
[2019/05/12 추기]
@taiba 선생님께서 저에게 Cannot do --run with go1.11 using go mod under windows. #217의 주석을 달다 해결 방안을 제시했다고 알려주셨습니다.