メインコンテンツへスキップ

Go Proposal Weekly Digest

Go言語のproposal更新を毎週お届け

#78350hold

cmd/go: change GO111MODULE=auto to have GO111MODULE=on behavior

ステータス変更: active hold

要約

AIによる要約であり、誤りを含む場合があります。

概要

GO111MODULE=auto（未設定時のデフォルト）の動作を変更し、GO111MODULE=onと同じ振る舞いにすることを提案しています。これにより、goコマンドが起動時点でGOPATHモードかモジュールモードかを確定できるようになり、内部実装の簡略化が可能になるというものです。

ステータス変更

active → hold
2026年6月10日のProposal Review Meeting（@aclements, @adonovan, @cherrymui, @griesemer, @ianlancetaylor, @neild, @rolandshoemaker出席）にて、このproposalはhold（保留）に移行されました。直接の変更を行う前に、@cherrymui が提案した代替手法（auto設定時に内部でその場でonまたはoffを判定し再実行する方式）をGo 1.28で試みるという合意が形成されたためです。この内部リファクタリングによって動機となったコードの複雑性が解消できるか検証し、その結果を踏まえて本proposalを再検討する方針となりました。

技術的背景

現状の問題点

GO111MODULE=autoは、go.modファイルがカレントディレクトリまたはその親ディレクトリに存在する場合はモジュールモードで、そうでない場合はGOPATHモードで動作する、という「状況依存」な設定です。
この仕組みによりgoコマンドの起動時点では動作モードが確定せず、例えばツールチェーン選択のコード（toolchain/select.go内のWillBeEnabled関数）はモジュールあるいはワークスペース内にいるかどうかをチェックしてから動作モードを判断する必要があります。これが複数箇所にわたる複雑性を生み出しています。
もともとGOPATHモードは廃止予定だったため、この複雑性は「短期的なもの」として許容されていました。しかし#60915のproposalが「GO111MODULE=offを設定した際のGOPATHモードは無期限に維持する」と決定したため、今後も長期にわたってこの複雑性と付き合い続けることになる問題が顕在化しました。

提案された解決策

GO111MODULE=autoを設定（または未設定）した場合に、GO111MODULE=onと全く同じ動作をするよう変更します。GOPATHモードを使いたいユーザーは明示的にGO111MODULE=offを設定することが求められるようになります。
過去にもautoの意味は変更されており（#31857: $GOPATH/src配下でも自動的にGOPATHモードに入らないよう変更）、今回の変更もその延長線上にあると位置付けられています。

これによって何ができるようになるか

本proposalが承認された場合、goコマンドの内部実装が簡略化されます。

  • ツールチェーン選択ロジックが起動時に動作モードを即座に確定できる
  • GOPATHモード関連のコードが他のロジックに干渉しないよう分離でき、新機能追加や変更が容易になる
  • 将来的なgoコマンドの改善（ワークスペース管理、ツールチェーン選択など）がシンプルになる

コード例

// Before: GO111MODULE=auto（デフォルト）の場合の動作
// - go.modが存在するディレクトリ: モジュールモードで動作
// - go.modが存在しないディレクトリ（GOPATH内）: GOPATHモードで動作
// 開発者はディレクトリによって自動的にモードが切り替わることを期待できた
// After: このproposalが承認された場合
// GO111MODULE=auto はGO111MODULE=on と同一の動作になる
// GOPATHモードを使う場合は明示的に設定が必要:
// $ export GO111MODULE=off
// $ go build ./...  # GOPATHモードでビルド
// モジュールモードに戻す場合:
// $ export GO111MODULE=on  (またはunset GO111MODULE)
// $ go build ./...  # モジュールモードでビルド

議論のハイライト

  • ユーザーからの反発: @rittnejを始めとする一部のユーザーが、新旧のGoリポジトリを混在して開発するチームではautoが重要なワークフローを支えていると指摘。autoがなければGOPATHモード/モジュールモードの切り替えを手動で行わなければならなくなる
  • 代替手法の提案: @cherrymui が「autoを廃止するのではなく、内部でonかoffかを判定してから再実行するアーキテクチャにすることで、外部動作を変えずに内部の複雑性を解消できる」と提案。@matloobもこのアプローチを支持
  • hold移行の理由: 変更の動機が「内部コードの簡略化」という点について、@ianlancetaylorが「コードの簡略化の価値とユーザーワークフローの破壊とをどう比較するか」と疑問を呈した。代替手法で同等の内部簡略化が達成できる可能性があるため、まずそちらを試みることになった
  • 段階的移行の示唆: @thepuddsはauto廃止の前に警告メッセージを出すリリース（1回目）と実際に変更するリリース（2回目）という2段階のアプローチも提案。また$GOPATH/go.envなど、より汎用的な設定ファイルの仕組みで多くのユースケースに対応できる可能性も示唆
  • 実際の利用状況: GOPATHモードを現在でも活発に使用しているユーザー（@qiulaidongfeng等）は、スクリプト実行や小規模ツール開発、標準ライブラリの挙動確認など、モジュール初期化不要の軽量なワークフローのためにautoを利用していることが明らかになった

関連リンク