Skip to content

Why Hatch?

Hatchの高レベルの価値命題は、すべての機能を採用すれば、必要なものすべてがサポートされるため、他の多くのツールが不要になるということです。さらに、特定の機能のみを使用することを選択した場合でも、代替機能と比較してメリットがある。

Build backend

build backend姉妹プロジェクトであるHatchlingには、setuptoolsと比較して多くの利点がある。ここでは、ほとんどの人がよく知っているsetuptoolsのみを比較する。

  • より良いデフォルト: setuptoolsのデフォルトの動作は、平均的なユーザーにとって望ましくないことがよくあります。
    • ソース配布の場合、setuptoolsには、デフォルトで含まれるファイルと除外されるファイルのカスタム列挙があります。Hatchlingは、Gitの.gitignoreファイルなどのバージョン管理システムからdefaultsを取得します。
    • ホイールの場合、setuptoolsはPythonパッケージのように見えるすべてのディレクトリを検索しようとします。これは、テストディレクトリやツールディレクトリなど、意図せずにエンドユーザーにファイルを送信する可能性があるため、望ましくないことがよくあります。Hatchlingdefaultsは、プロジェクト名に基づいて非常に具体的なインクルージョンになり、ヒューリスティックが満たされない場合はエラーになります。
  • 構成が容易: 孵化個体は、setuptoolsを構成する際の重要な課題の履歴に基づいて設計されています。
    • Hatchlingは、ほとんどのユーザがよく知っているすべてのオプションに対して、Git自体と同じグロブパターン構文を使用する。一方、setuptoolsはソース配布にシェルスタイルのグロブパターンを使用するのに対し、ホイールはシェルスタイルのグロブとPythonパッケージ構文を組み合わせて使用する。
    • ソースディストリビューションに何を含めるかを設定するには、別のMANIFEST.in fileが必要です。カスタム構文とディレクティブを学習する必要があり、setup.pyのようなメインファイルのどのオプションがどのような条件下で動作に影響するかを知ることは困難です。Hatchlingでは、[tool.hatch.build.targets.wheel]のような特定のターゲット専用のセクションの下にある単一のファイルですべてがconfiguredされます。
    • デフォルトでは、Python以外のファイルはホイールから除外されます。このようなファイルを含めるには、通常、ネストされたすべてのパッケージディレクトリに対して詳細な規則が必要です。Hatchlingはファイルタイプを区別せず、すでによく知られている一般的なビルドシステムのように動作します。
  • 編集可能なインストール: Hatchlingのデフォルトの動作では、IDEなどの外部ツールによる適切な静的解析が可能です。setuptoolsを使用する場合は、additional configurationを提供する必要がある。これは、たとえば、デフォルトではVisual Studio Codeでオートコンプリートを取得しないことを意味する。これはレガシー機能としてマークされており、実際にはsetuptoolsの将来のバージョンで削除される可能性がある。
  • 再現性: 孵化個体は、デフォルトで再現性のある車輪とソース分布を構築する。ソース分布のためのsetuptoolsdoes not support thisであり、車輪が再現性があるという保証はない。
  • 拡張性: extendsetuptoolsは可能ですが、APIは非常に低レベルです。Hatchlingにはpluginsという概念があり、個別のタイプに分割され、必要なものだけを公開するため、開発者のエクスペリエンスが容易になります。

Why not?:

拡張モジュールの構築が必要な場合は、引き続きsetuptoolsを使用するか、コンパイラとのインターフェイスに特化した他のバックエンドを使用することをお勧めします。

Environment management

ここでは、"tox"と"nox"の両方と比較します。高いレベルでは、いくつかの共通の利点があります。:

  • Python管理: 環境が要求する特定のバージョンが見つからない場合、HatchはPython distributionsをオンザフライで自動的にダウンロードできます。不明なディストリビューションを無視するオプションを使用すると、代替案でエラーが発生します。

  • 哲学: 代替案では、環境はほとんどの場合、依存関係セットがアクションに関連付けられている実行可能ユニットとして扱われます。コンテナエコシステムに精通している場合、これはDockerfileの最後にCMDを定義するようなものですが、実行時にアクションを変更する機能はありません。これは通常、アクションにわずかな変更を必要とすることが多く、異なるロジックを実行するためだけに基本構成から継承されたまったく異なる環境を定義するため、かなりのディスク領域の無駄を伴います。さらに、これは構成の面だけでなく、異なる環境の実行に関してもユーザーを混乱させる可能性があります。

    Hatchでは、environmentsは、実行時に任意のコマンドを実行できる独立した領域として扱われます。たとえば、scriptsという名前の単一のテスト環境を定義して、ユニットテストと非ユニットテストを実行できます。各コマンドは非常に長い可能性がありますが、インターフェイスを制御できるように任意の名前を付けることができます。環境は作業が実行される場所として扱われるため、shell of choiceに自動的にドロップするサブプロセスを実行するanyにシェルをspawnすることもできます。シェルは、PATH上のpythonのように適切に設定され、選択した環境を反映するようにプロンプトが変更されます。

  • Configuration:

    • toxはINI設定のみをサポートしており、それを標準のpyproject.tomlファイルに入れたい場合は、構文の強調表示を妨げるINI設定を含む複数行の文字列でなければならない。Hatchは、Pythonエコシステムの他のほとんどのツールと同様に、TOMLベースの設定を可能にします。
    • noxconfigはPythonで定義されているため、多くの場合、冗長性が増し、既知の動作を持つ標準化されたフォーマットと比較して、オンボードが困難になります。

  • Extensibility:

    • toxは、その機能のほとんどの側面をextendingすることができるが、APIは非常に低レベルであり、内部に接続されているため、プラグインを作成するのは困難な場合がある。たとえば、hereは、同等のHatchenvironment collector pluginにmigratedされたtoxプラグインです。530
    • noxはPythonで設定されているので、ローカルプロジェクトでは好きなことができますが、サードパーティのプラグインという概念自体はありません。これを実現するには、通常noxをラップするパッケージを使用し、代わりにそのパッケージのインポートを使用する必要があります(example)。

Why not?:

noxを使用していて移行したい場合、そして何らかの理由でnotifyセッションを行っている場合、移行は単純な変換ではなく、むしろその条件付きステップを再設計する必要があるかもしれません。

Python management

ここでは、Python managementとpyenvを比較する。

  • クロスプラットフォーム: Hatchはシステムに関係なく同じエクスペリエンスを可能にしますが、pyenvはWindowsをサポートしていないため、機能をエミュレートしようとするentirely different projectを使用する必要があります。
  • ビルドの依存関係がない: Hatchは、すべてのavailable distributionが事前にビルドされていることを保証するが、代替案では、プラットフォームや潜在的にPythonのバージョンによって異なる正確なbuild environmentを維持する必要がある。これのもう1つの利点は、ディストリビューションが簡単にダウンロードされて解凍されるため、インストールが非常に高速であることです。
  • デフォルトで最適化:* CPython distributionsは、プロファイルガイド付き最適化とリンク時間最適化を使用して構築されており、ワークロードに応じて10～30%のパフォーマンス向上が得られます。これらのディストリビューションは業界全体で広く採用されており、ビルドシステムBazelでも使用されている。

  • シンプルさ: Hatchは、PythonのインストールをPATHに追加する別のディレクトリとして扱います。これを行うことも、PATHを自分で管理してカスタムインストールの場所を指定することもできます。一方、pyenvはshimsを追加することで動作し、実際の基礎となるバイナリのラッパーとして機能します。これには多くの残念な副作用があります。

    • CLIを介してどの特定のPythonが最初に表示されるかを管理し、必要に応じて切り替え、および/またはプロジェクトごとにグローバルおよびローカルに公開されるバージョンのメンタルモデルを持つことは、ユーザの義務です。これはすぐに混乱する可能性がある。Hatchを使用する場合、グローバルPythonインストールは、環境がそれらを直接使用するのではなく、それらから仮想環境を作成し、常にプロジェクトと互換性のあるバージョンを使用するため、どこかのPATHにある限り重要です。
    • 各シェルが起動時にpyenvを適切に設定するための設定が必要であり、シェルを生成しないプロセスを実行する場合に不整合が発生します。
    • Pythonの検索パスに関する問題のデバッグは、特にソフトウェアのユーザーにとって非常に困難な場合があります。予期していなかったコードが実行されるという問題に遭遇したことがある場合、その問題はほとんどの場合、pyenvがPATHのpythonに影響を与えています。

Why not?:

現在、Hatchでは、特定のパッチリリースバージョンのインストールは許可されておらず、最新のパッチリリースを追跡するマイナーリリースの粒度のみを使用しています。特定のパッチリリースが重要な場合は、別のインストールメカニズムを使用することをお勧めします。