2018年2月に執筆された記事。



Goはパッケージのバージョン管理を追加する必要があります。



より正確には、Go開発者の作業辞書とツールにバージョン管理の概念を追加して、どのプログラムをビルド、実行、または分析するかに言及するときに全員が同じバージョン番号を使用するようにする必要があります。 go



コマンドは、特定のアセンブリに含まれるパッケージのバージョンを正確に通知する必要があります。



バージョン番号を使用すると、再現可能なアセンブリを作成できます。プログラムの最新バージョンを投稿すると、コードの最新バージョンだけでなく、コードが依存するすべてのパッケージとまったく同じバージョンも受け取るため、完全に同等のバイナリファイルが作成されます。



また、バージョン管理により、明日は今日とまったく同じプログラムがビルドされます。 依存関係の新しいバージョンがリリースされても、 go



は特別なコマンドなしではそれらを使用しません。



バージョン管理を追加する必要がありますが、 go



コマンドの主な利点を放棄すべきではありません。それは、単純さ、速度、およびわかりやすさです。 今日、多くのプログラマーはバージョンに注意を払っておらず、すべてが正常に機能しています。 適切なモデルを作成すれば、プログラマーはバージョン番号に注意を払うことなく、すべてがうまく機能し、より明確になります。 既存のワークフローはほとんど変わりません。 新しいバージョンのリリースは非常に簡単です。 一般に、バージョン管理は途中で行われるべきであり、開発者の注意を奪うべきではありません。



要するに、パッケージのバージョン管理を追加する必要がありますが、break go get



を追加する必要はありませgo get



。 この記事では、これを行う方法を提案し、今すぐ試すことができるプロトタイプを示します。プロトタイプは、 go



統合の基礎になることを願っています。 この記事が、何が機能して何が機能しないかについての生産的な議論の始まりになることを願っています。 この議論に基づいて、提案とプロトタイプの両方を調整し、Go 1.11にオプション機能を追加するための公式提案を提示します。



この提案はgo get



すべての利点を保持しますが、再現可能なビルドを追加し、セマンティックバージョン管理をサポートし、自動販売を排除し、プロジェクトベースのワークフローを優先してGOPATHを削除し、 dep



およびその前身からのスムーズな出発を提供します。 ただし、この提案はまだ初期段階です。 詳細が正しくない場合、作業がメインのGoディストリビューションに入る前に修正します。

一般的な状況

提案を検討する前に、現在の状況とその結果を見てみましょう。 このセクションは少し大きすぎるかもしれませんが、歴史は重要な教訓をもたらし、私たちが何かを変えたい理由を理解するのに役立ちます。 これが面白くない場合は、すぐにオファーにアクセスするか、例付きの付随するブログ記事を読むことができます。

Makefile



、 goinstall



およびgo get

2009年11月、Goの初期バージョンでは、コンパイラ、リンカー、およびいくつかのライブラリがリリースされました。 プログラムをコンパイルしてリンクするには、 6g



と6l



を実行する必要があり、キットにサンプルのメイクファイルを含めました。 最小限のgobuild



シェルは、1つのパッケージをコンパイルし、対応するmakefileを作成できます（ほとんどの場合）。 他の人とコードを共有する確立された方法はありませんでした。 これだけでは不十分であることがわかっていましたが、コミュニティと一緒に残りの開発を計画していたものをリリースしました。



2010年2月、 gobuckを提案しました。これは、BitbucketやGitHubなどのソース管理システムのリポジトリからパッケージをダウンロードする簡単なコマンドです。 Goinstall



、現在一般的に受け入れられているインポートパスに関するGoinstall



導入しています。 しかし、当時は、これらの規則に従ったコードはありませんでした; goinstall



、最初は標準ライブラリ以外をインポートしないパッケージでのみ動作しました。 しかし、開発者はすぐに今日知っている単一の契約に移行し、公開されたGoパッケージのセットは全体的なエコシステムに成長しました。



また、GoinstallはMakefileを修正し、それによってカスタムビルドオプションの複雑さを修正しました。 パッケージ作成者が各ビルド中にコードを生成できないことは時々不便ですが、この単純化はパッケージユーザーにとって非常に重要です。作成者が使用したのと同じツールセットをインストールすることを心配する必要はありません。 この単純化は、ツールの操作にとっても重要です。 Makefileは、パッケージをコンパイルするために必要なステップバイステップのレシピです。 go vet



やオートコンプリートなどの別のツールを同じパッケージに適用するのは非常に困難です。 依存関係を正しく取得し、必要に応じて必要な場合にのみパッケージを再構築することは、任意のMakefileでははるかに複雑です。 当時、一部の人々は柔軟性を奪われていることに反対しましたが、振り返ってみると、Makefileを放棄することが正しいステップだったことが明らかになりました。不便さをはるかに上回る利点があります。



2011年12月、Go 1の準備として、goコマンドを導入しました 。これはgoinstall



をgo get



置き換えgoinstall



。



一般に、 go get



は大きな変更go get



導入されています。Go開発者がソースコードを交換し、お互いの作業を使用できるようになりました。 また、 go



コマンド内でビルドシステムの一部を分離したため、ツールを使用して大幅な自動化が可能になりました。 しかし、バージョン管理の概念が欠けるgo get



ます。 goinstallの最初の議論で明らかになりました：バージョン管理で何かをする必要があります。 残念ながら、正確に何をすべきかは明確ではありませんでした。 少なくとも囲teamチームはこれを明確に理解していませんでした。 go get



パッケージを要求すると、常に最新のコピーが取得され、ダウンロードおよび更新操作がGitやMercurialなどのバージョン管理システムに委任されます。 このような「ブラインドワーク」は、少なくとも2つの重大な欠陥をもたらしました。

バージョン管理とAPIの安定性

go get



の最初の重大な欠点は、バージョン管理の概念がなければ、この更新で予期される変更についてユーザーに何も伝えることができないことです。



2013年11月、Go 1.2のバージョンには、バージョン管理に関するこのようなアドバイスを含むFAQエントリが追加されました（テキストはバージョンGo 1.10に変更されていません）。

一般的な使用のためのパッケージは、進化しても下位互換性を維持する必要があります。 Go 1の互換性に関する推奨事項がここに関連しています。エクスポートされた名前を削除したり、複合リテラルのタグ付けを推奨したりしないでください。 新しい機能が必要な場合は、古い名前を変更せずに、新しい名前を追加してください。 基本的な変更の場合は、新しいインポートパスを持つ新しいパッケージを作成します。

2014年3月、Gustavo Niemeyerは「Go言語用の安定したAPI」を装ってgopkg.inを立ち上げました 。 このドメインはバージョンgopkg.in/yaml.v1



GitHubリダイレクトであり、1つのGitリポジトリーのさまざまなコミット（おそらく異なるブランチ内）のgopkg.in/yaml.v1



やgopkg.in/yaml.v2



などのパスをインポートできます。 セマンティックバージョニングによると、作成者は重大な変更を行う場合、新しいメジャーバージョンをリリースする必要があります。 したがって、 v1



インポートパスの新しいバージョンは以前のものを置き換え、 v2



は完全に異なるAPIを提供できます。



2015年8月、Dave Cheney はセマンティックバージョン管理の提案を提出しました 。 次の数ヶ月間、これは興味深い議論を引き起こしました。バージョンのセマンティックタグ付けは素晴らしいアイデアであることに誰もが同意しているように見えましたが、これらのバージョンでツールがどのように機能するかは誰も知りませんでした



セマンティックバージョン管理の引数は、 ハイラムの法則を参照して必然的に批判されます。

十分な数のユーザーがいるAPIの契約は重要ではなくなります。 誰かは、システムの観察された動作に依存します。

Hyrumの法則は経験的に正しいものですが、セマンティックバージョン管理は、リリース間の関係に関する期待を生成するための有用な方法です。 1.2.3から1.2.4へのアップグレードでコードが破損することはありません。1.2.3から2.0.0へのアップグレードでも問題はありません。 1.2.4への更新後にコードが機能しなくなった場合、作成者はバグレポートを受け入れ、バージョン1.2.5のエラーを修正する可能性が高いでしょう。 2.0.0への更新後にコードが機能しなくなった（またはコンパイルされた）場合、この変更は意図的なものである可能性がはるかに高いため、2.0.1で何かが修正される可能性は低いです。



セマンティックバージョン管理は不可能であるとハイラムの法則から結論付けたくありません。 代わりに、作成者とまったく同じバージョンの各依存関係を使用して、アセンブリを慎重に使用する必要があると考えています。 つまり、既定のアセンブリは可能な限り再現可能である必要があります。

自動販売機および再現可能なアセンブリ

go get



の2番目の大きな欠点は、バージョン管理の概念がなければ、チームは再現可能なアセンブリのアイデアを提供したり、表現することすらできないことです。 ユーザーがあなたと同じバージョンのコード依存関係をコンパイルしていることを確認することはできません。 2013年11月、Go 1.2のFAQに次のFAQが追加されました。

外部パッケージを使用していて、予期せず変更される可能性がある場合、最も簡単な解決策はローカルパッケージにコピーすることです（このアプローチはGoogleで使用されています）。 ローカルコピーとして識別する新しいインポートパスでコピーを保存します。 たとえば、 original.com/pkg



you.com/external/original.com/pkg



をyou.com/external/original.com/pkg



コピーできます。 この手順のツールの1つに、Keith Rerikがいます。

Keith Rarikは2012年3月にこのプロジェクトを開始しました。 goven



ユーティリティは、依存関係をローカルリポジトリにコピーし、すべてのインポートパスを更新して新しい場所を反映します。 このようなソースコードの変更は必要ですが、不快です。 新しいコピーを比較して含めるのが難しくなり、この依存関係を使用して他のコピーされたコードを更新する必要があります。



2013年9月、 キースはgodep 、「パッケージの依存関係を修正するための新しいツール」を導入しました 。 godep



の主な成果は、現在ベンダーと呼ばれているものです。つまり、GOPATHを特定の方法で設定することにより、ソースファイルを変更せずに、ツールを直接サポートせずに依存関係をプロジェクトにコピーします。



2014年10月、キースはGoツールに「外部パッケージ」のサポートを追加することを提案しました。これにより、ツールはこの規則を使用してプロジェクトをよりよく理解できます。 その頃には、いくつかのgodep



スタイルのユーティリティがすでに登場していました。 Matt Farinaはgodep



とgodep



、特にglide



比較した「Go of Sea godep



マネージャーの旅」を投稿しました。



2015年4月、Dave Cheney はgbを導入しました 。「プロジェクトベースのビルドツール...ソースベンディングによる反復可能なビルド」、インポートパスを書き換えることなく常に便利というわけではありません）。



その春、Jason Buberlieは、Goパッケージ管理システムの状況を調査しました。これには、複数の作業の重複や、同様のユーティリティの無駄な作業が含まれます。 彼の調査により、開発者はインポートコマンドを書き換えずに自動販売をサポートするにはgo



コマンドに追加する必要があることが明らかになりました。 同時に、Daniel Theofanesは、ベンダーのディレクトリにあるコードの正確な起源とバージョンを記述するファイル形式の仕様を準備し始めました。 2015年6月、キースの提案をGo 1.5での販売に関する実験として受け入れました。Go1.5にはデフォルトで含まれていました。 すべての自動販売ツールの作成者がダニエルと協力して、単一のメタデータファイル形式を採用することを推奨しました。



Goでの自動販売の概念の導入により、 vet



などのツールはプログラムをより有能に分析できるようになり、今日では12つか2つのパッケージマネージャーまたは自動販売ツールで使用されています。 一方、誰もが異なるメタデータ形式を持っているため、相互作用せず、依存関係情報を簡単に交換できません。



より基本的には、販売はバージョン管理の問題に対する不完全な解決策です。 アセンブリの再現性のみを提供しますが、パッケージのバージョンを理解し、使用するパッケージを決定するのに役立ちません。 glide



やdep



などのパッケージマネージャーは、バージョン管理の概念をGoに暗黙的に追加し、特定の方法でベンダーディレクトリを設定します。 その結果、Goエコシステムの多くのツールは正しいバージョン情報を取得できません。 Goがパッケージバージョンを直接サポートする必要があることは明らかです。

公式パッケージ管理実験

Hack Day（現在のCommunity Day）のGopherCon 2016では、Goの活動家グループが集まり、 パッケージ管理の問題について広く議論しました 。 その結果の1つは、 新しいパッケージ管理ツールを作成することを目的として、さまざまな活動を実施するための委員会と諮問グループの設立でした。 アイデアは、既存のツールを統合ツールに置き換えることでしたが、ベンダーカタログを使用してGoの直接ツールキットの外部に実装されます。 委員会には、Peter Burgon率いるAndrew Gerrand、Ed Muller、Jesse Frazel、Sam Boyerが含まれていました。 彼らは仕様草案を準備した後、サムと彼の助手たちはdepを実装しました 。 一般的な状況の理解については、サムの2016年2月の記事「So You Want to Write Package Manager」 、2016年12月の投稿「Dependency Management Saga at Go」 、GopherConでの2017年7月のスピーチ「A New Era of Package Management in行け 。 」



Dep



は多くのタスクを実行します。これは、現在のプラクティスに対する重要な改善です。 これは、将来のソリューションに向けた重要なステップであると同時に、「公式実験」と呼ばれる実験であり、開発者のニーズをよりよく理解するのに役立ちます。 ただし、 dep



、パッケージのバージョン管理におけるgo



コマンドの可能な統合の直接的なプロトタイプでdep



ません。 これは、設計決定の空間を探索するための強力で柔軟な、ほぼ普遍的な方法です。 これは、最初に戦ったメイクファイルに似ています。 しかし、設計決定のスペースをよりよく理解し、サポートする必要があるいくつかの重要な機能にそれを絞り込むことができるとすぐに、これはGoエコシステムが他の機能を削除し、表現力を減らし、Goコードベースをより一貫性のある、より理解しやすくするバインディング規則を採用するのに役立ちます。



この記事は、 dep



後の次のステップの始まりですgoinstall



コマンドとの最終的な統合の最初のプロトタイプであり、 goinstall



相当するバッチgoinstall



。 プロトタイプは、 vgo



と呼ばれる別個のチームです。パッケージのバージョン管理をサポートするgo



代替品です。 これは新しい実験であり、その結果がわかります。 goinstall



発表時と同様に、一部のプロジェクトとコードはvgo



と互換性がありますが、他のプロジェクトとコードは変更が必要です。 システムを簡素化し、ユーザーの複雑さを排除するために、メイクファイルが削除されたのと同様に、コントロールと表現力をいくらか削除します。 最も重要なことは、可能な限り多くのレビューを得るためにvgo



実験を支援する先駆者を探していることです。



vgo



して実験を開始することは、 dep



サポートを停止することを意味するものではありませんvgo



との完全かつオープンな統合を達成するまで利用可能です。 また、この統合がどのような形態であっても、 dep



から統合への最終的な移行を可能な限りスムーズにしようとします。 まだdep



変換されていないプロジェクトは、この変換の恩恵を受けることができます（ godep



とglide



アクティブな開発を停止し、depへの移行を促進しglide



ことに注意してください）。 おそらく、一部のプロジェクトでは、ニーズに応じてvgo



直接切り替えたい場合があります。

申し出

go



コマンドにバージョン管理を追加する提案は、4つのステップで構成されています。 最初に、FAQおよびgopkg.inで示されているインポート互換性ルールを受け入れます。指定されたインポートパスを持つパッケージの新しいバージョンは、古いバージョンとの下位互換性が必要です。 第二に、このアセンブリで使用されるパッケージのバージョンを決定するための最小バージョンの選択として知られる、単純な新しいアルゴリズムを採用します。 3番目に、Go モジュールの概念を導入します 。全体としてバージョン管理されるパッケージのグループであり、依存関係によって満たされる必要がある最小要件を宣言します。 第4に、これらすべてを既存のgo



コマンドに統合して、基本的なワークフローが今日から大きく変わらないようにする方法を決定します。 この記事の残りの部分では、これらの各ステップを見ていきます。 これらについては、 他のブログ記事で詳しく説明しています。

インポート互換性ルール

パッケージ管理システムの主な問題は、非互換性を解決しようとする試みです。 たとえば、ほとんどのシステムでは、パッケージBでバージョン6以降のパッケージDが必要であることを宣言し、パッケージCでバージョン5以降ではなくDバージョン2、3、または4が必要であることを宣言できます。 したがって、パッケージでBとCを使用する場合は、運が悪いことになります。両方の条件を満たすDのバージョンを選択することはできず、何もできません。



必然的に大きなプログラムのアセンブリをブロックするシステムの代わりに、私たちの提案はパッケージ作成者のためのインポート互換性ルールを導入します：

古いパッケージと新しいパッケージのインポートパスが同じ場合、新しいパッケージには古いパッケージとの下位互換性が必要です。

このルールは、前述のFAQを繰り返します。 そのテキストは「急進的な変更が発生した場合、新しいインポートパスで新しいパッケージを作成します」という言葉で終わりました。今日、このような劇的な変化のために、開発者はセマンティックバージョン管理に依存しているため、提案に統合します。特に、2番目以降のメジャーバージョンの数は、パスに直接含めることができます。

 import "github.com/go-yaml/yaml/v2"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セマンティックバージョン管理では、バージョン2.0.0は根本的な変更を意味するため、新しいインポートパスで新しいパッケージが作成されます。各メジャーバージョンには異なるインポートパスがあるため、特定のGo実行可能ファイルには、メジャーバージョンの1つが含まれている場合があります。これは予想されることであり望ましいことです。このようなシステムはプログラムのアセンブリをサポートし、非常に大きなプログラムの一部をv1からv2に個別に個別にアップグレードできます。



作成者がインポート互換性ルールに準拠すると、システム全体が指数関数的に単純化され、パッケージエコシステムの断片化が減少するため、非互換性を解決する試みがなくなります。もちろん、実際には、作成者のすべての努力にもかかわらず、同じメインバージョン内の更新によってユーザーパッケージが破損する場合があります。したがって、頻繁に更新しないでください。これにより、次のステップに進みます。

最小バージョン選択

今日では、など、ほぼすべてのパッケージマネージャ、dep



およびcargo



、許容パケットの最新バージョンのアセンブリで使用されています。このデフォルトの動作は2つの理由で間違っていると思います。第一に、「最後に許可されたバージョン」の数は、外部イベント、つまり新しいバージョンの公開により変化する可能性があります。たぶん今夜誰かが依存関係の新しいバージョンを導入し、明日今日実行したコマンドの同じシーケンスは異なる結果を与えるでしょう。第二に、このデフォルトを上書きするために、開発者は、パッケージマネージャ「いいえを指して自分の時間を過ごす、X»を使用する必要はないが、その後、パッケージマネージャがするのに時間がかかるXを使用しない方法を見つけます。



私たちの提案では、別のアプローチを使用しています。これを最小バージョンの選択と呼びます。デフォルトでは、各パッケージの許可されている最も古いバージョンが使用されます。古いバージョンを公開することは不可能であるため、この決定は明日変更されません。さらに良いことに、パッケージマネージャーが使用するバージョンを決定するのは簡単です。選択したバージョン番号が最小であり、またシステム全体もおそらく最小であるため、これを最小バージョンの選択と呼びます。これは、既存システムのほとんどすべての複雑さを回避するためです。



最小バージョンを選択すると、モジュールは依存関係の最小要件のみを指定できます。これらは、更新操作とダウングレード操作の両方に対して明確に定義された一意の回答であり、これらの操作は本当に効果的です。この原則により、モジュール全体の作成者は、除外する依存関係のバージョンを示したり、特定の依存関係をローカルストレージにあるか別のモジュールとして公開されているそのフォークに置き換えたりすることができます。モジュールが他のモジュールの依存関係として構築されている場合、これらの例外と置換は適用されません。これにより、ユーザーは自分のプログラムをどのようにアセンブルするかを完全に制御できますが、他のプログラムは制御できません。



最小バージョンを選択すると、デフォルトでロックファイルなしで再現可能なアセンブリが提供されます。



インポートの互換性は、最小バージョンを選択しやすくするための鍵です。ユーザーは「いいえ、これはあまりにも新しいバージョンです」と言うことはできません。「いいえ、古い」としか言えません。この場合、解決策は明確です。（最小）新しいバージョンを使用してください。また、慣例により新しいバージョンは、古いバージョンの代替として受け入れられます。

Goモジュールの定義

Go モジュールは、モジュールパスと呼ばれる共通のインポートパスプレフィックスを持つパッケージのコレクションです。モジュールはバージョン管理ユニットであり、バージョンはセマンティック文字列として記述されます。 Gitを使用して開発する場合、開発者はモジュールのGitリポジトリにタグを追加することにより、モジュールの新しいセマンティックバージョンを定義します。セマンティックバージョンを指定することを強くお勧めしますが、特定のコミットへのリンクもサポートされています。



新しいファイルでは、go.mod



モジュールは依存する他のモジュールの最小バージョン要件を定義します。たとえば、次は簡単なファイルですgo.mod



。

 // My hello, world. module "rsc.io/hello" require ( "golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54 "rsc.io/quote" v1.5.2 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルは、パスrsc.io/hello



で識別されるモジュールを定義し、他の2つのモジュールに依存します：golang.org/x/text



とrsc.io/quote



。モジュールアセンブリ自体は、ファイルにリストされている必要な依存関係の特定のバージョンを常に使用しますgo.mod



。大きなアセンブリの一部として、アセンブリの他の部分で必要な場合にのみ新しいバージョンを使用できます。



作成者は、リリースにセマンティックバージョンvgo



をマークし、任意のコミットではなくマークされたバージョンの使用を推奨します。rsc.io/quote



付属のモジュールには、github.com/rsc/quote



1.5.2などのマーク付きバージョンがあります。ただし、モジュールにはまだgolang.org/x/text



フラグ付きバージョンがありません。タグなしコミットに名前を付けるには、擬似バージョンv0.0.0-yyyymmddhhmmss-commit特定の日付に特定のコミットを定義します。セマンティックバージョン管理では、この行は識別子yyyymmddhhmmss-commitの v0.0.0プレリリースに対応しています。バージョン優先のセマンティックルールは、バージョンv0.0.0より前のリリースなどのプレリリースを認識し、文字列の比較を実行します。擬似バージョンの日付順により、文字列比較が日付比較と一致することが保証されます。



これらの要件に加えて、ファイルgo.mod



は前のセクションで述べた例外と置換を示すことができますが、これも分離されたモジュールをビルドするときにのみ適用され、大きなプログラムの一部としてビルドするときは適用されません。これはすべて例で示されています。



Goinstall



そして古いgo get



コードをダウンロードすることなどのバージョン管理ツールを起こしgit



やhg



断片化を含む多くの問題につながります。たとえばbzr



、Bazaarリポジトリからコードをダウンロードできないユーザー。このシステムとは異なり、Goモジュールは常にzipアーカイブの形式でHTTP経由で発行されます。以前はgo get



、人気のあるコードホスティングサイト専用のチームがありました。現在、vgo



これらのサイトからアーカイブを受信するための特別なAPIプロシージャがあります。



zipアーカイブ形式のモジュールの統一された表示により、モジュールをロードするためのプロトコルとプロキシサーバーを簡単に実装できます。企業や個々のユーザーは、セキュリティや、オリジナルを削除した場合にキャッシュされたコピーを使用したいなど、プロキシサーバーを起動する理由が異なります。プロキシを配置すると、アクセシビリティを確保go.mod



し、使用するコードを決定するために、ベンダーディレクトリが不要になります。

チーム go

モジュールを使用するには、コマンドgo



を更新する必要があります。主な変更点の一つは、通常のビルドのようなコマンドであることをgo build



、go install



、go run



とgo test



、新しい依存関係の需要が可能になります。golang.org/x/text



完全に新しいモジュールで使用するには、インポートをGoソースコードに追加してビルドします。



しかし、最も重要な変更は、コードを記述する場所としてGOPATHに別れを告げることです。ファイルにgo.mod



はモジュールへのフルパスが含まれ、使用される各依存関係のバージョンも決定するため、ファイルのあるディレクトリは、他のディレクトリとはgo.mod



別に、スタンドアロンワークスペースとして機能するディレクトリツリーのルートをマークします。今、あなただけやっていますgit clone



、cd



、書き込みを開始します。どこでも。ゴーパスなし。

次は？

使用方法のデモを含むGoバージョン管理ツアーも公開しましたvgo



。その記事では、今すぐダウンロードして使用を開始する方法について説明していますvgo



。他の記事のその他の情報。コメントさせていただきます。



vgoを試してください。セマンティックタグを使用して、リポジトリ内のバージョンのタグ付けを開始します。ファイルを作成しますgo.mod



。リポジトリ内の空のファイルならばという注意go.mod



が、そこにあるdep



、glide



、glock



、godep



、godeps



、govend



、govendor



または設定ファイルはgvt



、その後、vgo



ファイルを取り込むためにそれらを使用していますgo.mod



。



Goがバージョンサポートでこの延滞の一歩を踏み出していることを嬉しく思います。 Go開発者が直面する最も一般的な問題のいくつかは、再現可能なビルドの欠如、リリースタグの完全な無視です。go get



、GOPATHがパッケージの異なるバージョンを認識できないこと、GOPATHの外部のディレクトリで作業できないこと。ここで提供される設計は、これらの問題すべてを排除します。



しかし、私はおそらくいくつかの詳細に誤りがあります。プロトタイプvgo



をテストし、生産的な議論に参加することで、読者がそれを改善できるよう願っています。 Go 1.11には、一種のデモとしてGoモジュールの予備サポートが付属し、Go 1.12には公式サポートが追加されました。それ以降のバージョンでは、古い非バージョンのサポートを削除しますgo get



。しかし、これは積極的な計画であり、正しい機能を実現するために後のリリースを待つ必要がある場合は、そうする必要があります。



古いものからの移行がとても心配ですgo get



新しいモジュラーシステム用の無数のベンダーツール。このプロセスは、適切な機能と同じくらい重要です。移行が成功するということは、その後のリリースを待つことを意味する場合、それでもまたそうです。