Why Hatch?¶なぜHatchなのか？¶

The high level value proposition of Hatch is that if one adopts all functionality then many other tools become unnecessary since there is support for everything one might require. Further, if one chooses to use only specific features then there are still benefits compared to alternatives.Hatchの高レベルな価値提案は、すべての機能を採用すれば、多くの他のツールが不要になるということです。なぜなら、必要なすべてのサポートがあるからです。さらに、特定の機能のみを使用することを選択した場合でも、代替手段と比較して依然として利点があります。

Build backend¶バックエンドの構築¶

Hatchling, the build backend sister project, has many benefits compared to setuptools. Here we only compare setuptools as that is the one most people are familiar with.Hatchling、ビルドバックエンドの姉妹プロジェクトは、setuptoolsと比較して多くの利点があります。ここでは、ほとんどの人が馴染みのあるsetuptoolsのみを比較します。

Better defaults: The default behavior for setuptools is often not desirable for the average user.
- For source distributions, setuptools has a custom enumeration of files that get included and excluded by default. Hatchling takes the defaults from your version control system such as Git's .gitignore file.ソース配布の場合、setuptoolsはデフォルトで含まれるファイルと除外されるファイルのカスタム列挙を持っています。Hatchlingは、Gitの.gitignoreファイルなど、バージョン管理システムからのデフォルトを取得します。
- For wheels, setuptools attempts to find every directory that looks like a Python package. This is often undesirable as you might ship files to the end-user unintentionally such as test or tooling directories. Hatchling defaults to very specific inclusion based on the project name and errors if no heuristic is satisfied.ホイールの場合、setuptoolsはPythonパッケージのように見えるすべてのディレクトリを見つけようとします。これは、テストやツールディレクトリなど、意図せずにエンドユーザーにファイルを送信する可能性があるため、しばしば望ましくありません。Hatchlingは、プロジェクト名に基づいて非常に特定の含めるデフォルトを使用し、ヒューリスティックが満たされない場合はエラーを返します。
Ease of configurability: Hatchling was designed based on a history of significant challenges when configuring setuptools.
- Hatchling uses the same glob pattern syntax as Git itself for every option which is what most users are familiar with. On the other hand, setuptools uses shell-style glob patterns for source distributions while wheels use a mix of shell-style globs and Python package syntax.Hatchlingは、すべてのオプションに対してGit自体と同じグロブパターン構文を使用しており、これはほとんどのユーザーが馴染みのあるものです。一方、setuptoolsはソース配布に対してシェルスタイルのグロブパターンを使用し、ホイールにはシェルスタイルのグロブとPythonパッケージ構文の混合を使用します。
- Configuring what gets included in source distributions requires a separate MANIFEST.in file. The custom syntax and directives must be learned and it is difficult knowing which options in the main files like setup.py influence the behavior and under what conditions. For Hatchling, everything gets configured in a single file under dedicated sections for specific targets like [tool.hatch.build.targets.wheel].ソース配布に含まれるものを設定するには、別の MANIFEST.in ファイルが必要です。カスタム構文とディレクティブを学ぶ必要があり、setup.py のようなメインファイルのどのオプションが動作に影響を与えるか、またその条件を知るのは難しいです。Hatchlingでは、すべてが単一のファイルで特定のターゲット用の専用セクションの下に設定されます。例えば [tool.hatch.build.targets.wheel] のように。
- By default, non-Python files are excluded from wheels. Including such files requires usually verbose rules for every nested package directory. Hatchling makes no such distinction between file types and acts more like a general build system one might already be familiar with.デフォルトでは、非Pythonファイルはホイールから除外されます。そのようなファイルを含めるには、通常、すべてのネストされたパッケージディレクトリに対して冗長なルールが必要です。Hatchlingはファイルタイプの区別をせず、すでに馴染みのある一般的なビルドシステムのように動作します。
Editable installations: The default behavior of Hatchling allows for proper static analysis by external tools such as IDEs. With setuptools, you must provide additional configuration which means that by default, for example, you would not get autocompletion in Visual Studio Code. This is marked as a legacy feature and may in fact be removed in future versions of setuptools.編集可能なインストール: Hatchlingのデフォルトの動作は、IDEなどの外部ツールによる適切な静的解析を可能にします。setuptoolsを使用する場合、追加の設定を提供する必要があり、例えばデフォルトではVisual Studio Codeでのオートコンプリートが得られません。これはレガシー機能としてマークされており、将来のsetuptoolsのバージョンで削除される可能性があります。
Reproducibility: Hatchling builds reproducible wheels and source distributions by default. setuptools does not support this for source distributions and there is no guarantee that wheels are reproducible.再現性: Hatchlingはデフォルトで再現可能なホイールとソース配布をビルドします。setuptoolsはソース配布に対してこれをサポートしていませんし、ホイールが再現可能である保証はありません。
Extensibility: Although it is possible to extend setuptools, the API is quite low level. Hatchling has the concept of plugins that are separated into discrete types and only expose what is necessary, leading to an easier developer experience.拡張性: setuptoolsを拡張することは可能ですが、APIはかなり低レベルです。Hatchlingにはプラグインの概念があり、これらは異なるタイプに分けられ、必要なものだけを公開するため、開発者の体験が容易になります。

Why not?:なぜダメなのか？:

If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.拡張モジュールのビルドが必要な場合は、setuptoolsを引き続き使用するか、コンパイラとのインターフェースに特化した他のバックエンドを使用することをお勧めします。

Environment management¶環境管理¶

Here we compare to both tox and nox. At a high level, there are a few common advantages:ここでは tox と nox を比較します。高レベルでは、いくつかの共通の利点があります：

Python management: Hatch is able to automatically download Python distributions on the fly when specific versions that environments request cannot be found. The alternatives will raise an error, with the option to ignore unknown distributions.Python管理: Hatchは、環境が要求する特定のバージョンが見つからない場合に、Pythonディストリビューションを自動的にダウンロードすることができます。代替手段はエラーを発生させ、未知のディストリビューションを無視するオプションがあります。
Philosophy: In the alternatives, environments are for the most part treated as executable units where a dependency set is associated with an action. If you are familiar with container ecosystems, this would be like defining a CMD at the end of a Dockerfile but without the ability to change the action at runtime. This involves significant wasted disk space usually because one often requires slight modifications to the actions and therefore will define entirely different environments inherited from a base config just to perform different logic. Additionally, this can be confusing to users not just configuration-wise but also for execution of the different environments.哲学: 代替案では、環境は主に実行可能な単位として扱われ、アクションに関連付けられた依存関係セットがあります。コンテナエコシステムに慣れている場合、これはDockerfileの最後にCMDを定義するようなもので、実行時にアクションを変更する能力はありません。これには通常、アクションにわずかな変更が必要なため、異なるロジックを実行するためだけにベース構成から継承されたまったく異なる環境を定義することが多く、かなりのディスクスペースの無駄が伴います。さらに、これは設定面だけでなく、異なる環境の実行においてもユーザーにとって混乱を招く可能性があります。

In Hatch, environments are treated as isolated areas where you can execute arbitrary commands at runtime. For example, you can define a single test environment with named scripts that runs unit vs non-unit tests, each command being potentially very long but named however you wish so you get to control the interface. Since environments are treated as places where work is performed, you can also spawn a shell into any which will execute a subprocess that automatically drops into your shell of choice. Your shell will be configured appropriately like python on PATH being updated and the prompt being changed to reflect the chosen environment.Hatchでは、環境は、実行時に任意のコマンドを実行できる孤立した領域として扱われます。たとえば、名前付きのスクリプトを持つ単一のテスト環境を定義し、ユニットテストと非ユニットテストを実行できます。各コマンドは非常に長くなる可能性がありますが、好きなように名前を付けることができるため、インターフェースを制御できます。環境は作業が行われる場所として扱われるため、任意の環境にシェルを生成することもでき、サブプロセスが自動的にあなたの選択したシェルにドロップします。あなたのシェルは、pythonが更新されたPATHに適切に設定され、プロンプトが選択した環境を反映するように変更されます。
Configuration:設定:
- nox config is defined in Python which often leads to increased verbosity and makes it challenging to onboard folks compared to a standardized format with known behaviors.noxの設定はPythonで定義されているため、標準化された形式と既知の動作に比べて、冗長性が増し、オンボーディングが難しくなることがよくあります。
Extensibility:
- tox allows for extending most aspects of its functionality however the API is so low-level and attached to internals that creating plugins may be challenging. For example, here is a tox plugin that was migrated to an equivalent Hatch environment collector plugin.toxは、その機能のほとんどの側面を拡張することを許可しますが、APIは非常に低レベルで内部に結びついているため、プラグインを作成するのが難しい場合があります。たとえば、こちらは、toxプラグインで、移行されたHatchの環境コレクタープラグインに相当します。
- nox is configured with Python so for the local project you can do whatever you want, however there is no concept of third-party plugins per se. To achieve that, you must usually use a package that wraps nox and use that package's imports instead (example).noxはPythonで設定されているため、ローカルプロジェクトでは好きなことができますが、第三者プラグインの概念はありません。それを実現するには、通常、noxをラップするパッケージを使用し、そのパッケージのインポートを使用する必要があります（例）。

Why not?:なぜそうしないのか?:

If you are using nox and you wish to migrate, and for some reason you notify sessions, then migration wouldn't be a straight translation but rather you might have to redesign that conditional step.noxを使用していて移行したい場合、そして何らかの理由でセッションを通知する場合、移行は単純な翻訳ではなく、その条件付きステップを再設計する必要があるかもしれません。

Python management¶Python管理¶

Here we compare Python management to that of pyenv.ここでは、Python管理をpyenvと比較します。

Cross-platform: Hatch allows for the same experience no matter the system whereas pyenv does not support Windows so you must use an entirely different project that tries to emulate the functionality.クロスプラットフォーム: Hatchは、システムに関係なく同じ体験を提供しますが、pyenvはWindowsをサポートしていないため、機能をエミュレートしようとするまったく異なるプロジェクトを使用する必要があります。
No build dependencies: Hatch guarantees that every available distribution is prebuilt whereas the alternative requires one to maintain a precise build environment which differs by platform and potentially Python version. Another benefit to this is extremely fast installations since the distributions are simply downloaded and unpacked.ビルド依存関係なし: Hatchは、すべての利用可能なディストリビューションが事前にビルドされていることを保証します。一方、代替手段では、プラットフォームやPythonのバージョンによって異なる正確なビルド環境を維持する必要があります。これにより、ディストリビューションが単にダウンロードされて解凍されるため、非常に高速なインストールが可能になります。
Optimized by default: The CPython distributions are built with profile guided optimization and link-time optimization, resulting in a 10-30% performance improvement depending on the workload. These distributions have seen wide adoption throughout the industry and are even used by the build system Bazel.デフォルトで最適化: CPythonディストリビューションは、プロファイルガイド最適化とリンク時最適化を使用してビルドされており、ワークロードに応じて10-30%のパフォーマンス向上を実現しています。これらのディストリビューションは業界全体で広く採用されており、ビルドシステムBazelでも使用されています。
Simplicity: Hatch treats Python installations as just another directory that one would add to PATH. It can do this for you or you can manage PATH yourself, even allowing for custom install locations. On the other hand, pyenv operates by adding shims which then act as wrappers around the actual underlying binaries. This has many unfortunate side effects:
- It is incumbent upon the user to manage which specific Python comes first via the CLI, switch when necessary, and/or have a mental model of which versions are exposed globally and locally per-project. This can become confusing quite quickly. When working with Hatch, your global Python installations are only important insofar as they are on PATH somewhere since environments do not use them directly but rather create virtual environments from them, always using a version that is compatible with your project.ユーザーは、CLIを介してどの特定のPythonが最初に来るかを管理し、必要に応じて切り替え、またはプロジェクトごとにグローバルおよびローカルでどのバージョンが公開されているかのメンタルモデルを持つ必要があります。これが非常に混乱を招くことがあります。Hatchを使用する際、グローバルなPythonインストールは、環境がそれらを直接使用するのではなく、それらから仮想環境を作成するため、PATH上にある限り重要です。常にプロジェクトに互換性のあるバージョンを使用します。
- Configuration is required for each shell to properly set up pyenv on start, leading to inconsistencies when running processes that do not spawn a shell.各シェルの設定には、pyenvを正しく起動時に設定するための構成が必要であり、シェルを生成しないプロセスを実行する際に不整合が生じる可能性があります。
- Debugging issues with Python search paths can be extremely difficult, especially for users of software. If you or users have ever ran into an issue where code was being executed that you did not anticipate, the issue is almost always pyenv influencing the python on PATH.Pythonの検索パスに関する問題のデバッグは非常に難しい場合があります。特にソフトウェアのユーザーにとってはそうです。もしあなたやユーザーが、予期しないコードが実行される問題に直面したことがあるなら、その問題はほぼ常にpyenvがPATH上のpythonに影響を与えていることが原因です。

Why not?:なぜダメなのか？:

Currently, Hatch does not allow for the installation of specific patch release versions but rather only uses minor release granularity that tracks the latest patch release. If specific patch releases are important to you then it is best to use an alternative installation mechanism.現在、Hatchは特定のパッチリリースバージョンのインストールを許可しておらず、最新のパッチリリースを追跡するマイナーバージョンの粒度のみを使用しています。特定のパッチリリースが重要な場合は、代替のインストールメカニズムを使用するのが最良です。