問題タブ [godeps]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
495 参照

heroku - Godep 処理カスタム パッケージ

これが私の問題です。自分で作成したカスタム パッケージを使用する go-app があります。このパッケージを git などで公開したくありません。それらは、特定の機能を備えた単なるパッケージです。

したがって、私のプロジェクト フォルダーは次のようになります。

パッケージをvendorフォルダーに配置します。

さて、私main.goはこのパッケージを正常にインポートしました:

そして、すべてがうまくいきます。

ここで、プロジェクトを heroku にデプロイする準備をしたいと思いgodepます。だから、私が実行する私のプロジェクトのルートフォルダで

そして、ここに私の問題があります-私のパッケージはすでにvendorフォルダーにあるため、エラーが発生します:

godep: パッケージ (github.com/u-mulder/package_one) が見つかりません

もちろん、すべてのパッケージに対してプロジェクトを作成できます。の構造は次のsrcようになります。

その後、上記の問題はなくなりましたが、2番目の問題が発生します。

godep: 検査中にエラーが発生しました"$GOPATH/src/github.com/u-mulder/package_one": ディレクトリ"$GOPATH/src/github.com/u-mulder/package_one"は既知のバージョン管理システムを使用していません

もちろん.git、各プロジェクト パッケージにリポジトリを作成することもできます (この問題はなくなるかもしれません)。

それで、問題は、カスタム(またはローカル)パッケージをどこに配置して、godepそれらを見つけて「実際の」パッケージにしたくないかということです。

ここで見つけた似たようなものですが、それはvendorフォルダーに関するものではありません。

0 投票する
1 に答える
91 参照

go - 依存関係をインストールするときに「go get ./...」を修正するにはどうすればよいですか?

「go get ./...」と入力すると、次のように返されます。

このエラーを修正するにはどうすればよいですか? または、どうすればこれをデバッグできますか? これは古いバージョンの go...バージョン 1.5.2 用です。他の情報を提供できる場合はお知らせください。そのままローカルで問題なく動作するため、どこから始めればよいか本当にわかりません。前もって感謝します。

0 投票する
3 に答える
803 参照

go - Golang の内部依存関係管理

私が働いている会社には、Go で書かれたいくつかのバックエンド システムがあり、コードの一部はそれらの間で共有されています。バックエンド システムは個別に展開する必要があり、場合によっては異なるマシンに展開する必要があります。これらのプロジェクトはすべてまだ活発に開発されており、かなり頻繁に変更されています。

私たちは、git リポジトリとそれらの間の依存関係を管理する良い方法を見つけようとしています。

現時点では、共有コード用のリポジトリが 1 つあります。これをバックエンド共有と呼びましょう。次に、バックエンド システムごとに個別のリポジトリを用意します。それらを backend1 および backend2 と呼びましょう。次に、各バックエンドは backend-shared に対する Godep 依存関係を持ちます。

私が理解している限り、Golang での依存関係管理の推奨される方法は、すべての依存関係が /vendor ディレクトリにコピーされ、バージョン管理にチェックインする必要があるベンダーによるものです。このようにして、すべての依存関係が特定のバージョンにロックされます。

これは、外部の依存関係に対しては問題なく機能しますが、バックエンド共有の内部依存関係については、開発者が特定のバックエンド システムとバックエンド共有システムの両方に同時に変更を加える必要があることは珍しいことではないため、非常に面倒になります。

現在、開発者の GOPATH に存在する backend-shared に変更が加えられた場合、その変更は backend1 内 (GOPATH でも) には表示されません。 /vendor ディレクトリ。

したがって、backend-shared の新しいバージョンをコピーするために backend1 を再ベンダー化するか、/vendor ディレクトリから backend-shared を一時的に削除して、インポートが GOPATH 内のバージョンを指すようにする必要があります。 . これらのオプションは両方とも潜在的に汚いと感じており、それらがGoの使用方法であるかどうかはわかりません.

私の質問は、現在のリポジトリを維持し、一度に複数のプロジェクトの開発を簡素化するためのより良い方法があるかどうかです?

それとも、すべてのリポジトリを単一のリポジトリに結合する必要がありますか? 現在、依存関係の観点からバックエンド 1 とバックエンド 2 が分離されていても、それらの開発ライフサイクルがかなり絡み合っていることを考えると?

backend1、backend2、および backend-shared を含む単一のリポジトリから始めなかった主な理由は、backend1 と backend2 を別々にデプロイする必要があるため、それらのコードも物理的に分離したかったからです。