web-dev-qa-db-ja.com

GOPATH外のGoプロジェクトのソースコードを持っているのは悪い考えです

私はGoを使用して新しいプロジェクトに取り組んでおり、私たちはすべてGoを初めて使用します。標準のgoディレクトリ構造に従い、すべてのコードを

$ GOPATH/src/github.com/companyname/projectname

これはgitリポジトリのルートでもあります

標準の推奨パスレイアウトは、特に多言語プロジェクト（たとえば、 Goベースのrest/httpバックエンド、およびhtml/javascriptフロントエンド。その場合、プロジェクト構造を次のようにしたいと思うでしょう。

/
  doc/
  src/
    server/
      main.go
      module1/
        module.go
    client/
      index.html
  Makefile

しかし、実際にはコードをGOPATH内に配置する必要がありますか？

試みとして、ソースコードがGOPATHの外にある小さなプログラムを作成しました。プロジェクトをパッケージに簡単に分割できるので、mainパッケージはfoo/フォルダー内のfooパッケージをimport "./foo"を使用して参照できます。

私が見る限り、これによって私が許可されないことが2つあります。

  • 他のコードはこのコードをインポートできません。私たちは会社のために特別にサービスを構築しているので、これは問題ではありません。
  • インストールにgo installを使用できません。これも問題ではありません。ビルドパイプラインはツールをインストールします。

ただし、ビルドサーバーがワークスペースをGOPATH内に配置しないようにすることはできます。

そのようなアプローチは推奨されませんか？もしそうなら、なぜそうですか？

上に挙げた2つの副作用以外の悪影響はありますか？

これは会社のプライベートプロジェクトであり、パブリックオープンソースコードではないことに注意してください。

実際のプロジェクトをGOPATHから切り離すのは魅力的なようですが、 Sh ステージにいるときは、規則に違反しないように注意してください。

go
34
Pete

2019更新

プロジェクトをGOPATHに保存する必要がなくなりました。

GOPATH以外のディレクトリに配置します。次に、次のように入力します。

go mod init github.com/youruser/yourproject

あなたは行ってもいいでしょう。

5
Inanc Gumus

GOPATHを使用する必要はありませんが、goコマンドから取得したすべてのNiceツールを利用できません。それらはすべて、コードが標準のGOPATH階層にあることを期待しています。

go install、 だけでなく go test（そしてニースgo test -coverカバレッジツール）が機能しませんgo getを使用すると、リモートコードをダウンロードして、すべてをGOPATHに書き込むことができるため、コピーする必要があります。

確かに、すべてをmake/scons/cmake/whateverで置き換えて処理を行うと、環境に応じて機能する可能性がありますが、goツールで追加の処理を実行できます。

13
iccananea

（免責事項：私はこのようなものをデザインするのが好きですが、Goは初めてです。実際には試していません）

アイデア：なぜ両方ではないのですか？

シンボリックリンクを考慮に入れると、2つの極性オプションを利用できます。

（A）ワークスペースにシンボリックリンクされたsrcのコード

/
  doc/
  src/
    server/
      projectname/
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname -> ../../../src/server/projectname
      github.com/
        someone/
          library/
    bin/
    pkg/
  Makefile

（b）srcにシンボリックリンクされたワークスペース内のコード

/
  doc/
  src/
    server/
      projectname -> ../../go_workspace/src/companyname/projectname
    client/
      index.html
  go_workspace/
    src/
      companyname/
        projectname/
      github.com/
        someone/
          somelib/
    bin/
    pkg/
  Makefile

私は「A」に寄りかかると思います。

  • すべてのソースは物理的に一緒に住んでいます
  • projectnameは簡単に独自のリポジトリを持つことができます。または、プロジェクト全体に対して1つのリポジトリを持つことができます。
  • あなたは全体を保つことができますgo_workspaceバージョン管理外で、makeステップを介して初期化します（godepを使用してからプロジェクトにシンボリックリンクします）
9
Kos