web-dev-qa-db-ja.com

「mod」パッケージを認識するようにgolangを構成するにはどうすればよいですか？

私はgo1.11rc1を試してみましたが、最初に気づいたのは、golandがインポートを認識しないことです。

golandバージョンアナウンスメント は次のように述べています：「そのまま使用できるGoモジュール（以前のvgo）のサポート」

誰でもこれを修正する方法を知っていますか？

問題：

  1. 「github.com/urfave/cli」などのパッケージの色が赤で、ホバーテキストに「ディレクトリを解決できません...」と表示されます
  2. 「app：= cli.NewApp（）」の「NewApp」などのインポートされたパッケージアイテムの色が赤で、ホバーテキストに「未解決の参照...」と表示されます

再現する手順：

  1. Go1.11rc1をインストールします。現在のインストールを削除し、1.11rc1をインストールし、バージョンを確認します。
  2. Goパスの外側に新しいプロジェクトディレクトリを作成します：mkdir pjg && cd pjg
  3. go.modファイルを作成します：go mod init github.com/stevetarver/pjg
  4. プロジェクトにパッケージを追加します：go get github.com/urfave/cli

go.modファイルは次のようになります。

module github.com/stevetarver/pjg/v1

require github.com/urfave/cli v1.20.0 // indirect

main.goを作成：

package main

import (
    "fmt"
    "log"
    "os"

    "github.com/urfave/cli"
)

func main() {
    app := cli.NewApp()
    app.Name = "boom"
    app.Usage = "make an explosive entrance"
    app.Action = func(c *cli.Context) error {
        fmt.Println("boom! I say!")
        return nil
    }

    err := app.Run(os.Args)
    if err != nil {
        log.Fatal(err)
    }
}

Golandでmain.goを表示し、赤いテキストにカーソルを合わせて問題を確認します。

  • modパッケージは$GOPATH/pkg/mod/に保存されます
  • ゴーランドバージョン：2018.2.1
  • バージョン：go1.11rc1 darwin/AMD64

ノート：

  • $GOPATHは正しく設定されています-go getはパッケージを正しい場所に配置し、envのGOPATHはgolandの設定に一致します。
  • Golandプリファレンスの設定Go-> GOPATH-> Module GOPATH to /Users/starver/code/go/pkg/modはこれを修正しませんでした。
gogoland
7
Steve Tarver

GoLandサポート

GoLandの最新バージョンはvgoおよびgoモジュールのサポートを実装しましたが、go1.11rc1構文の変更に追いついていません。それが暫定的に誰かを助ける場合に備えて、私が試したものと彼らの問題と成功を文書化します。

TL; DR：プロジェクトを$GOPATHに入れずに、新しいプロジェクトを「Go Module（vgo）」タイプとして作成します。OR turn既存のプロジェクトではその設定が有効です。

Go1.11rc1をグローバルgoとしてインストールすると、GoLandのgo modプロジェクトには3つの基本的な使用例があります...

新しいプロジェクトを作成しますinside$GOPATH：

  1. 「Go Module（vgo）」タイプの新しいプロジェクトを作成します。File-> New、「Go Module（vgo）」を選択します
  2. プロジェクトディレクトリを$GOPATH内の何かに設定します：$GOPATH/src/github.com/stevetarver/insidegopath
  3. main.goに存在しないパッケージを参照する$GOPATHファイルを作成します。
  4. そのパッケージをインポートに追加します。

Gifで説明されているvgoを介したgo get GoLandの使用 here ：

  1. インポートパッケージをクリックします。
  2. 赤い検査電球をクリックします。
  3. 「…のパッケージを同期」をクリックします。
  4. [〜＃〜] fail [〜＃〜]：go: go mod -sync is now go mod tidy

go getを使用して、GoLand組み込みのターミナル方法：

  1. 組み込み端末を開きます。
  2. go getインポート。
  3. [〜＃〜] fail [〜＃〜]：ᐅ go get github.com/urfave/cli go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src; ignoring go.mod; see 'go help modules'

その変数をオンにして、再試行してみましょう。

  1. 注：端末プラグインの設定には、環境変数を設定する方法はありません。
  2. GO111MODULE=onを設定：[設定]-> [外観と動作]-> [パス変数]を開き、GO111MODULE=onを追加します。
  3. ターミナルを終了し、再試行し、GoLandを再起動して、上記と同じ失敗を再試行します。
  4. ターミナルのenv | grep GO111MODULEは何も生成しません。
  5. [〜＃〜] note [〜＃〜]：これがうまくいけば、それは悪い解決策だっただろう-GoLandにはプロジェクトごとの設定がないようだこれ-その変数は、goモジュールの準備ができていないプロジェクトを壊すすべてのプロジェクトでオンになっていたでしょう。
  6. この答え によれば、このenv varを含むカスタムコマンドラインランチャーを作成できますが、eeuuwww-GoLandを正常に起動するタイミングとコマンドラインランチャーを使用するタイミングをどのように追跡しますか？

シェルの初期化スクリプトでGO111MODULE=onを設定できますが、それはまだgoモジュールを使用していないすべてのプロジェクトを破壊します。

各goコマンドの前にenv var：export GO111MODULE=on; go get github.com/urfave/cliを付けるか、これを行うプロジェクトディレクトリにgo Shellスクリプトラッパーを作成することもできます。

これらのどれも実際に実行可能なソリューションではありませんが、ポイントオブゴーモジュールの一部は恐ろしいゴーワークスペースからの脱出ですので、読んでください、それは良くなります

新しいプロジェクトを作成しますoutside$GOPATH：

  1. 「Go Module（vgo）」タイプの新しいプロジェクトを作成します。File-> New、「Go Module（vgo）」を選択します
  2. プロジェクトディレクトリを$GOPATH以外の場所に設定します
  3. go.modを修正します。生成されたファイルにはmodule "outsidegopath"が含まれますが、module github.com/stevetarver/outsidegopathのようなものが必要です。これは少し不安定です-GoLandはgo.modを書き換え、パスの一部を削除しようとします。数回繰り返すと、試行が停止します。
  4. main.goファイルを作成します。 ideを介してgoファイルとして作成する場合、package outsidegopathが含まれます。 package mainになるように修正します。
  5. これでgo get github.com/urfave/cliができ、期待どおり$GOPATH/pkg/modにフェッチされます。

go modサポートを既存の新しいプロジェクトに追加します。

これは本当に簡単であることが判明しました-GoLandでgoモジュールを操作する最良の方法：

  1. 環境設定を開きます：Go-> Go Module（vgo）、および「Enable Go Modules（vgo）integration」をチェックします
  2. 上記のように機能しますが、go.modを使用して独自のgo mod init module-nameを作成します。
8
Steve Tarver

モジュール管理 Go 1.13（2019年8月）の方が簡単です：

GO111MODULE環境変数は引き続きデフォルトでautoに設定されますが、現在の作業ディレクトリにgo.modファイルが含まれているか、その下にある場合は、auto設定がgoコマンドのモジュール対応モードをアクティブにします— 現在のディレクトリがGOPATH/src内にある場合でも。

この変更により、GOPATH/src内の既存のコードの移行と、モジュールを認識しないインポーターとともにモジュールを認識できるパッケージの継続的なメンテナンスが簡単になります。

つまり、「プロジェクトを$GOPATHに入れないでください」という部分はすべて不要になります。
go.modファイルがある限り、コマンドラインからモジュールが認識されます またはIDE から。

1
VonC