1.1　PEPとは？PyPAとは？

　Pythonの言語仕様や推奨される規則、その仕様に至った歴史、論理的根拠などを記録した設計文書のことを「PEP」と呼称します¹。PEPはPython Enhancement Proposalの略です。Pythonの実装は「PEP xxxに準拠した実装」などのように行われています。簡単に言えば「PEPは、Pythonインタプリタが従うべき仕様書」となります。Pythonインタプリタの仕様のみでなく、Python言語として推奨コーディング規約などもPEPで定められています²。

　Pythonで作成したコード一式を配布する際は、パッケージングを行い配布パッケージの形にまとめます（この後で改めて説明します）。このようなPythonでのパッケージと配布のエコシステムの標準仕様を策定、管理しているワーキングループを「PyPA」と呼称します。PyPAはPython Packaging Authorityの略です³。

1.2　モジュールとは？パッケージとは？

　Pythonで書かれた単一の*.pyファイルを「モジュール（Module）」と呼称します⁴。より正確には、「Pythonにおけるコードの再利用性の基本単位」として定義され、「Pure Module」⁵と「Extension Module」⁶の2種類に分かれますが、本書では以降「Pure Module」のことを指して「モジュール」と呼称します⁷。

　複数の「モジュール」を集約したディレクトリのことを「パッケージ」と呼称し、「パッケージ」を配布用に整えたものを「配布パッケージ」（もしくは「配布用のパッケージ」）と呼称します⁸。

　以降、本書ではモジュール、パッケージ、配布パッケージ、と括弧書きを付けずに記載します。

1.3　pipとは？wheelファイル形式とは？

　配布パッケージを取得してインストールする際には、Python標準に含まれているpipコマンド⁹が一般に利用されます。pipは「パッケージ管理システム」のひとつです。特に指定がない場合は、pipコマンドはWheelファイル形式¹⁰の配布パッケージを選好します¹¹。Wheelファイル形式の配布パッケージを用いると、利用者は特別なコンポーネントの構築ツールや経験を必要とせずに対象のパッケージを自身の環境で利用できます。Pythonで用いられる配布パッケージの形式はいくつか存在しますが、本書では以降で特に断らない場合は、PyPAが推奨するWheelファイル形式を指すものとします¹²。

　本書では、Wheelファイルのフォーマット¹³自体には踏み込みません。Wheelファイルを作成するためのツールの実行方法と、作成されたWheelファイルをローカルで利用する方法¹⁴、の観点で解説します。Wheelファイルをインターネットを通じて配布する方法に興味のある方は、付録E「Python配布パッケージをGitHubリポジトリで配布する方法」と付録F「Python配布パッケージをPyPIリポジトリで配布する方法」で簡単に触れていますので、参照ください。

1.4　仮想環境とは？（依存関係のローカルインストール方法）

　Pythonに標準で含まれているパッケージ以外の、任意のサードパーティー製のパッケージが提供する機能を利用する場面を考えます。機能の例としては、インターネットアクセスを容易にするパッケージである「requests」や、データ処理を（データのクレンジングを）容易にするパッケージである「pandas」、などを用いる場面です。

　これらの機能は、配布パッケージの形式でPyPIにて公開されているので、pipコマンドを用いて自身の利用環境へ簡単に追加できます（パッケージをインストールできます）。pipコマンドを単純に実行すると、対象パッケージはグローバル環境にインストールされます。そうすると、アプリケーションAではパッケージZのVersion 1.0を必要とするが、一方でアプリケーションBではパッケージZのVersion 2.0を必要とする、という場面で困ったことになります。これを解決するために、Pythonでは「Python仮想環境」という概念を利用します（以降、「仮想環境」と略す。とくに断らない限りPythonの仮想環境を指す）。標準に含まれない追加のパッケージをインストールする際には、必須ではありませんが仮想環境を構築してからインストールすることが推奨されます¹⁵。

　仮想環境を作成して、「その環境の中で」pipによるパッケージのインストールとアプリケーションを実行することで「アプリケーション固有の隔離された環境で実行」できます。仮想環境はそれ自身のインストールディレクトリを持ち、他の仮想環境とライブラリを共有しません。これにより、グローバル環境を汚さずにアプリケーションの動作に必要なパッケージの依存関係をアプリケーション単位でインストールできます。

　現在、次のふたつのPython仮想環境を構築するためのツール（パッケージとして提供）がよく知られています。

　・venv

　・virtualenv

　venvパッケージはvirtualenvのパッケージのサブセットであり、Pythonに標準で含まれているパッケージであり、pipコマンドによる追加インストールなしに利用できます。

　本書では、利用の簡単なvenvパッケージ（venvコマンド）を用いるものとします。仮想環境の具体的な利用方法は「2.3.1 仮想環境venvの作成」と「2.4.2 仮想環境poetry shellを作成」¹⁶で解説します。

1.5　パッケージ作成での推奨フォルダー構成

　配布することを考慮したパッケージを作成する際に、推奨されるフォルダー構成はリスト1.1の通りです。一般にこのような一式をプロジェクトと呼称し、ひとつのプロジェクトではひとつのパッケージを含めます。

リスト1.1: 配布を考慮したパッケージの推奨フォルダー構成

project_root
  +--[パッケージのメタ情報を記述したファイル].xxx
  +--・・・（ビルド方法や依存関係のパッケージなど）・・・
  |
  +--[パッケージ名]/
  |  +--[パッケージを構成するモジュール].py
  |  +--・・・
  |  |
  |  +--__init__.py
  |  +--__main__.py
  |
  +--[パッケージのテストコードなど]
  \--・・・

　リスト1.1は抽象度が高すぎるため、ある程度まで想定場面を絞ったサンプルを用いて、以降では推奨フォルダー構成を解説します。なお、配布パッケージの作成に用いるツールにより若干の差分があるため、実際に動作可能なファイル・フォルダー構成の具体例は、配布パッケージ作成の方式別に解説している第2章を参照ください。

　サンプルとして、「向こう1週間の天気の予想気温を取得する」機能を提供するパッケージ「weatherforecast」を作成する場面を考えます。このパッケージは、次のモジュールをまとめたもの（集約したもの）とします。ファイル名などは本節での限定的なものとします（第2章で用いるサンプルコードより抽象度が高いです）。

　・天気の予想気温を取得するモジュール「forecast.py」

　・取得した予想気温をインプットとして特性を出力するモジュール「analyse.py」

　これらのモジュールを集約したパッケージを作成する際に推奨されるファイル・フォルダー構成例はリスト1.2です¹⁷。これは最低限の要素での構成例です。

リスト1.2: 配布を考慮したパッケージのフォルダー構成例

project_root
  +--setup.py or pyproject.toml
  +--README.md
  +--LICENSE.txt
  |
  \--weatherforecast/
     +--forecast.py
     +--analyse.py
     +--__init__.py

　リスト1.2の構成要素は表1.1の通りです。

　リスト1.1において、次のファイル群は「パッケージのメタ情報を記述したファイル」に該当し、記載の通りの固定のファイル名での構成が推奨されます（変更できないわけではありません）。

　・setup.py

　・pyproject.toml

　・README.md

　・LICENSE.txt

　上記の他に、必要に応じて「requirements.txt」や「MANIFEST.in」ファイル、また「docs/」フォルダーなどを追加する場合もありますが、説明は割愛します。

　リスト1.1においてフォルダーは「パッケージ名」に該当します。

　・weatherforecast/

　このフォルダー名は任意です。PEP8に記載されている命名規約に沿って、パッケージの目的が分かりやすい名称を付けます¹⁹。このフォルダー配下に、パッケージにまとめるモジュール一式を格納します（__init__.py以外のモジュール名も任意です）。

　これらの他に、必要に応じて表1.2のようなフォルダー等を含める場合もありますが、説明は割愛します。