uv init したら親の pyproject.toml が勝手に書き換わった話 | TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
モノレポ構成において、各ディレクトリを独立したDockerイメージとしてデプロイしたい場合がある。しかし、uvはデフォルトで親ディレクトリを再帰的に探索し、ワークスペースのメンバーとして自動登録する仕様を持つ。これにより、プロジェクト間の疎結合性が失われ、ビルドコンテキストの肥大化や依存関係の意図しない共有が発生する。
// Approach
uv init実行時に--no-workspaceフラグを付与することで、親ディレクトリの探索をスキップし、当該ディレクトリを独立したプロジェクトとして初期化する手法を提示している。これにより、ルートのpyproject.tomlへの影響を防ぎ、個別のuv.lockおよび仮想環境の保持が可能となる。
// Result
ワークスペース構成と独立プロジェクト構成の差異を、ルートへの影響、ロックファイル、仮想環境の観点から比較。デプロイ単位が明確な構成では、--no-workspaceを活用することで、Dockerイメージの軽量化やCI/CDの最適化、環境の分離が容易になることを示している。
Senior Engineer Insight
> ツールの『親切なデフォルト挙動』が、システム設計の意図を破壊する典型的な事例である。モノレポにおいて、開発の利便性とデプロイの疎結合性はしばしばトレードオフの関係にある。特にDockerコンテナ化を前提とする場合、ワークスペースによる依存関係の集約は、ビルドコンテキストの肥大化やCI/CDの実行コスト増大を招く。エンジニアはツールのマジックに依存せず、アーキテクチャの要件に基づき、--no-workspaceのような明示的な制御を選択する審美眼を持つべきである。スケーラビリティを担保するためには、ツールの挙動を完全に制御下に置くことが不可欠だ。