Pythonプログラムをパッケージにして、pipでインストールできるwhlファイルを作成したり、PyPIに公開して広く一般に使ってもらったりする手順について紹介します。
ということで、どうも、ケンヂまるです。最近、Pythonのパッケージ作成にハマっています。
この1ヶ月、npindexやyen-parserといったパッケージを公開していました。さらに職場でも、他の人に使ってほしいプログラムは極力パッケージ化してから渡すようにすることで、使ってもらう敷居を下げたり、バージョンがよくわからない状態の未管理のソースコードが乱立するのを防いだりするのに活用しています。
Pythonでパッケージを公開する方法は色々とあるなかで、poetryを使う方法を選択しました。比較的新しいツールであるというのと、他の手段より洗練された使い勝手で学習コストが低いというのが理由です。poetryを使うのにも慣れてきたので、ここらで入門用の記事としてまとめてみようかと思い立った感じです。
インストール
poetryは一般的なPythonパッケージと違い、pipでのインストールは推奨されていません。代わりに、poetryのサイトに書いてあるコマンドをコピーして持ってきて、実行することでインストールします。
Mac OS・Linuxへのインストール
osx / linux / bashonwindows install instructionsからインストール用コマンドをコピーして、ターミナルに貼り付けて実行します。
> curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python -
これでインストールが完了し、ターミナルを再起動するとPATHの設定も反映されます。
> poetry -v
Poetry version 1.1.6
Windowsへのインストール
windows powershell install instructionsからインストール用コマンドをコピーして、PowerShellに貼りつけて実行します。
> (Invoke-WebRequest -Uri https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py -UseBasicParsing).Content | python -
なぜか手元の環境ではインストールしてPowerShellを再起動してもPATHが通りませんでした。
同じような方は、次のように自分でPATHを通すことで使えるようになります。
> $env:PATH += ";~\.poetry\bin"
ヘルプを眺めよう
インストールが完了したら、ヘルプを表示してどんな使い方なのか眺めてみましょう。
> poetry -h
Poetry version 1.1.6
USAGE
poetry [-h] [-q] [-v [<...>]] [-V] [--ansi] [--no-ansi] [-n] <command> [<arg1>] ... [<argN>]
ARGUMENTS
<command> The command to execute
<arg> The arguments of the command
GLOBAL OPTIONS
-h (--help) Display this help message
-q (--quiet) Do not output any message
-v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and
"-vvv" for debug
-V (--version) Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n (--no-interaction) Do not ask any interactive question
AVAILABLE COMMANDS
about Shows information about Poetry.
add Adds a new dependency to pyproject.toml.
build Builds a package, as a tarball and a wheel by default.
cache Interact with Poetry's cache
check Checks the validity of the pyproject.toml file.
config Manages configuration settings.
debug Debug various elements of Poetry.
env Interact with Poetry's project environments.
export Exports the lock file to alternative formats.
help Display the manual of a command
init Creates a basic pyproject.toml file in the current directory.
install Installs the project dependencies.
lock Locks the project dependencies.
new Creates a new Python project at <path>.
publish Publishes a package to a remote repository.
remove Removes a package from the project dependencies.
run Runs a command in the appropriate environment.
search Searches for packages on remote repositories.
self Interact with Poetry directly.
shell Spawns a shell within the virtual environment.
show Shows information about packages.
update Update the dependencies as according to the pyproject.toml file.
version Shows the version of the project or bumps it when a valid bump rule is provided.
コマンドがたくさんありますが、実際にパッケージ公開までに使用するのはこのうち10コマンドくらいです。
- add
- build
- config
- env
- init
- install
- new
- publish
- remove
- run
え？10コマンドは多い？大丈夫です、実際に使ってみると思ったより意味的にしっくりくるコマンドばかりなので、そんなに学習コストも高くないと思います。
それと、それぞれのコマンドにもヘルプがあって、
> poetry publish -h
といったようにコマンド名の後に "-h" を付けることでそのコマンドのヘルプも見ることができます。使い方を丸覚えするのはしんどいので、このヘルプを見ながら使いこなせることを意識してここからの説明を読み進めていってみて下さい。
poetryを使って配布可能パッケージを作成してみる
sample_hello()という関数を実行すると、画面に "Hello Poetry!" と表示する関数をパッケージとして公開してみましょう。
プロジェクトを作成する
poetry newコマンドで、プロジェクト一式を作成することができます。
> poetry new sample-library
Created package sample_library in sample-library
コマンドで指定した名前のディレクトリが作成され、README.rst、pyproject.toml、パッケージディレクトリ（sample_library）、testsテストディレクトリが作成されます。
sample-library
├── README.rst
├── pyproject.toml
├── sample_library
│ └── __init__.py
└── tests
├── __init__.py
└── test_sample_library.py
パッケージディレクトリの中には__init__.pyファイルが、testsテストディレクトリの中には__init__.pyとtest_sample_library.pyが作成されていて、公開するために最低限必要なファイルは揃っている状態が出来上がっています。
pyproject.tomlを設定する
公開するパッケージには、パッケージ名、バージョン、依存パッケージの情報などが必要ですが、そういった情報はpyproject.tomlに設定する必要があります。
pyproject.tomlの内容を適当に修正したものを載せておきます。内容の補足をコメントに書いているので参考にして下さい。詳細な説明については後半のpyproject.tomlの細かな設定で説明します。今はまずパッケージを作成してみることを目標に読み進めてみて下さい。
# tomlファイルでは "#" から始まる行はコメント
[tool.poetry]
# パッケージ名 "pip sample-library"としてインストールできるようになる
name = "sample-library"
# 最初のバージョンは一般的に0.1.0
version = "0.1.0"
# PyPIでパッケージ名のすぐ下に表示される一文
description = "My sample library"
# 著者情報 "名前 <メールアドレス>"という形式が一般的
authors = ["kenjimaru <kendimaru2@gmail.com>"]
[tool.poetry.dependencies]
# 自分の環境のPythonバージョンが初期値として設定されるが、
# 他のバージョンのPythonでも動作するプログラムなら"^3.6"としておくのが無難。
python = "^3.6"
# ここ以降は特段意識する必要は無い
[tool.poetry.dev-dependencies]
pytest = "^5.2"
[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"
公開用の関数を作成する
"Hello Poetry!"と表示するsample_hello()という関数をパッケージとして公開したいので、関数を定義します。
sample_library/__init__.pyに、直接sample_library関数を書いてしまいましょう。
__version__ = '0.1.0'
def sample_hello():
print("Hello Poetry!")
これで、関数が作成できました。
関数を使ってみる
関数を作ったら、ビルドする前に実際に自分で使ってみましょう。
そのためには、まず依存関係や今回作成しているsample_libraryパッケージを仮想環境にインストールします。
> poetry install
poetry installコマンドを実行すると仮想環境が作成され、そこにpyproject.tomlに記載されている依存情報を元に依存ライブラリがインストールされます。さらに今作っているパッケージであるsample_libraryもインストールされるので、作ったものを動かしてみる環境を自動的に作成することができます。
仮想環境はpoetryが管理する仮想環境置き場でまとめて管理されます。この場所はあまり意識する必要はないですが、どこに環境が作られたのか気になるという人はpoetry env info -pコマンドで確認してみて下さい。
仮想環境を作成したら、実際に動かしてみましょう。
動かすには、poetry runコマンドを使って、仮想環境上でpythonを動かします。
> poetry run python
Python 3.9.4 (default, Apr 5 2021, 01:50:46)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sample_library import sample_hello
>>> sample_hello()
Hello Poetry!
パッケージのインポートも関数の使用も問題なさそうなことが確認できました。
ビルドしてpipからインストール可能なwhlファイルを作成する
sample_hello()関数が動作することが確認できたので、これをパッケージファイルにしましょう。
poetry buildコマンドを実行するとdistディレクトリが作成され、その中にパッケージファイルが作成されます。
> poetry build
Building sample-library (0.1.0)
- Building sdist
- Built sample-library-0.1.0.tar.gz
- Building wheel
- Built sample_library-0.1.0-py3-none-any.whl
*.tar.gz形式のファイルと*.whl形式の2つのファイルが作成されますが、どちらもpipからインストールできます。
実際にインストールしてみましょう。
まず、仮想環境を別に作成して、そこにtar.gzファイルとwhlファイルをコピーします。
> cd ..
> mkdir check_install
> cp sample-library/dist/* check_install
> python3 -m venv venv
> source venv/bin/activate
(venv) > pip list
Package Version
---------- -------
pip 21.1.2
setuptools 57.0.0
作成したばかりの仮想環境なので、当然といえば当然ですが、pipとsetuptools以外はインストールされていない、まっさらな環境ですね。
では、インストールしてみましょう。
(venv) > pip install sample-library-0.1.0.tar.gz
Processing ./sample-library-0.1.0.tar.gz
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Building wheels for collected packages: sample-library
Building wheel for sample-library (PEP 517) ... done
Created wheel for sample-library: filename=sample_library-0.1.0-py3-none-any.whl size=1135 sha256=8c91b72db668ee147627a11fd20ebef752a75db790edcd19f264d2f4e50d6ece
Stored in directory: /Users/dimaru/Library/Caches/pip/wheels/b4/65/7f/fb45ff649611f0228e2abe4653a9be4d2604c2265eee86c908
Successfully built sample-library
Installing collected packages: sample-library
Successfully installed sample-library-0.1.0
(venv) > pip list
Package Version
-------------- -------
pip 21.1.2
sample-library 0.1.0
setuptools 57.0.0
インストールが成功して、自作のsample_libraryが動作する環境ができました。pipにsample_library-0.1.0-py3-none-any.whlを指定しても、同様にインストールできます。
確認が終わったらvenv環境を無効化するのを忘れずに。
(venv) > deactivate
tar.gzとwhlの違いについて
tar.gzはソースファイルなどが圧縮されたファイルで、解凍すると*.pyファイルを取り出すことができます。pipのインストールに指定するとビルドしてからインストールされます。
一方でwhlはあらかじめビルドされた状態になっていて、こちらの方がインストールは高速になります。ただし、環境ごとに対応したwhlでないとインストールできないという制約があります。今回作成したwhlはsample_library-0.1.0-py3-none-any.whlという名前で、"none"=OSでもインストール可能で、"any"=どのアーキテクチャのマシンでもインストール可能、となっています。
なので自分のビルドしたパッケージの名前を確認して、"-none-any.whl"というファイル名の場合は、どの環境に対してもwhlファイルを配布して問題なしです。逆にそうでない場合は、環境毎にあらかじめビルドしてから提供する必要があります。
PyPIに公開する
ビルドしたパッケージはwhlファイルを共有するなどして仲間内で使ってもいいですが、広く一般に使ってもらいたいならPyPIへの公開一択です。いきなりpypi.orgに公開するのはリスクが大きいので、テスト公開するためのtestPyPI (test.pypi.org)が用意されています。まずはこちらに公開して、問題なさそうならPyPIにも公開する、という流れを基本にしましょう。
アカウント登録
まずはtest.pypi.orgでアカウント登録します。
登録したメールアドレス宛に確認メールが送られてくるので、本文に含まれているリンクをクリックしてアカウントを有効化します。
APIトークンを作成
test.pypi.orgの管理画面が表示されるので、poetryからの接続用にAPIトークンを作成します。
管理画面右上のアカウント名をクリック→Account settings
少し下にスクロールして、API tokensからAdd API tokenをクリック
Token nameにはとりあえずfullとでも入力して、ScopeもEntire account(all projects)を選択し、Add tokenをクリック。
poetryにAPIトークンを登録
ターミナルに戻って、poetryにこのトークンを登録します。
> poetry config pypi-token.testpypi [コピーしたトークン]
testpypiというリポジトリに接続する時はこのトークンを使ってね、という設定です。
ちなみに、トークンの設定ができた確認しようとしてpoetry config --listと実行しても、たった今設定したはずのpypi-token.testpypiの設定は表示されません（表示されなくて何回も何回も何回も何回も何回も…設定した男より）。トークンはセキュリティ情報なので、その環境のキーリングに保存されます。もし環境にキーリングが設定されていない場合は、~/.config/pypoetry/auth.tomlなどに書き込まれる仕様になっているようです。
test.pypi.orgリポジトリをpoetryに登録
testpypiというリポジトリに接続する際のトークン設定はしましたが、じゃあtestpypiというリポジトリのURLはどこなのか、といった情報を、poetryはまだ知りません。
そこで、poetry configコマンドでtestpypiのリポジトリを登録します。
> poetry config repositories.testpypi https://test.pypi.org/legacy/
重要な所なのでしつこく言います。指定するのは https://test.pypi.org/legacy/ です。 https://test.pypi.org/legacy ではありません。何が違うのかというと、末尾のスラッシュ"/"のありなしです。スラッシュありが正解です。このスラッシュを忘れると、続いて説明するpoetry publishコマンド自体は成功するものの、実際にはtestpypiへの公開は失敗している、というハマりルートまっしぐらになります。（ハマった男の忠告）
これでようやく、testpypiに公開するための準備が完了です。
パッケージを公開する
それではtestpypiにsample-libraryを公開しましょう。
poetry publishコマンドを使うと、PyPIに公開することができます。-rオプションに、testpypiを指定します。
> poetry publish -r testpypi
Publishing sample-library (0.1.0) to testpypi
- Uploading sample-library-0.1.0.tar.gz 100%
- Uploading sample_library-0.1.0-py3-none-any.whl 100%
もしこれを読んでいるあなたが、この記事を読んで全く同じパッケージ名（"sample-library"）で作成している場合、アップロードは失敗するはずです。なぜなら、既に公開されているパッケージ名では公開できない仕様だからです。
sample-libraryというパッケージは僕がこの記事を書きながら公開してしまっているので、他のパッケージ名に変更してからアップロードしてみて下さい。変更するポイントは2箇所です。
pyproject.tomlのnameの値
name = "sample-library2"
パッケージディレクトリの名前（こちらはハイフンは使わずアンダーバーを使う）
> cp sample_library sample_library2
> poetry build
> poetry publish -r testpypi
これで、ビルドも公開も成功するはずです。（あ、ちなみにsample_library2も僕が確認で公開しているので使えませんよ😆）
公開できたか確認
公開した後は、test.pypi.orgで自分のパッケージを検索してみましょう。
ありましたか？では次は、test.pypi.orgから自分のマシンにパッケージをインストールしてみましょう。
# 先ほどインストール確認に使った環境へ
> cd ../check_install
# 仮想環境有効化
> source venv/bin/activate
# 先ほどインストールしたパッケージを削除
(venv) > pip uninstall sample-library
# test.pypi.orgからインストール（自分が公開したライブラリ名で試してみて下さい）
(venv) > pip install -i https://test.pypi.org/simple sample-library
Collecting sample-library
Downloading https://test-files.pythonhosted.org/packages/7d/8a/a7f8ca7f1397248cacf01605722ee31727f8ca730fa9bc5226b97053b979/sample_library-0.1.0-py3-none-any.whl (1.1 kB)
Installing collected packages: sample-library
Successfully installed sample-library-0.1.0
# 確認が終わったら仮想環境から抜け出しておこう
(venv) > deactivate
>
これで、test.pypi.orgを使って、自分のパッケージ公開が問題ないことが一通り確認できました。
testPyPIではなくPyPIに公開する手順もほぼ同じ
この次はpypi.orgに公開するわけですが、手順は先程とほぼ同じです。異なる点は、pypiのリポジトリを登録する必要がないのと、poetry publishコマンドに-rオプションを付ける必要がないことです。（どちらもpoetryのデフォルトの設定とされているので登録も指定も必要ない）
これで、初歩的なパッケージを公開することができました。PyPIのアカウント作成やAPIトークンの作成・登録などの手順が面倒だったと思いますが、次からは不要な部分になるので楽になると思います。
依存パッケージを追加する
公開するパッケージが何か他のライブラリを利用する場合は、依存ライブラリの管理が必要になります。poetry addコマンドを使うと依存ライブラリの追加、poetry removeコマンドで依存ライブラリの削除ができます。
前の章の説明が長くなってしまったので、ここでは新たにもう一度プロジェクトを作り直した方がわかりやすいですね。（この記事を書いている本人が訳がわからなくなってきているので仕切り直し😇）
色付き文字で "hello!" と出力するhello()関数を備えた、colored-helloパッケージを作ることにしましょう。
# プロジェクト作成
> poetry new colored-hello
# カレントディレクトリをプロジェクトの中へ移動
> cd colored-hello
文字に色を着けるため、coloramaパッケージを使います。coloramaは、出力文字の色などを変更する機能を備えているものとしましょう。
依存パッケージを追加
さて、coloramaパッケージを使うということは、依存パッケージとして扱わなければいけません。poetry addコマンドで、依存パッケージを追加できます。
# 依存ライブラリにcoloramaを追加
> poetry add colorama
poetry addコマンドは、次の仕事をします。
- pyproject.tomlの[tool.poetry.dependencies]テーブルに依存パッケージとして情報を追加する
- 仮想環境を（まだ無ければ）作成し、依存パッケージをインストールする
- poetry.lockという、インストールされているパッケージのバージョンロックファイルを作成または更新する
1番目のpyproject.tomlへの追加ですが、実は自分で記述することもできます。その場合は適切なバージョン番号を下べて適切な書式で記載します。2番目と3番目の仮想環境の作成は、poetry installコマンドと同じです。
依存パッケージを追加すると、poetry runコマンドで実行される以降の処理は、全てpoetry.lockに指定されているバージョンに従ったものになります。複数の開発者がいる場合、ライブラリをインストールするタイミングが異なると、依存ライブラリのバージョンが違ったものになってしまうといったリスクも、poetry.lockをバージョン管理システムで共有することで解決することができます。
>poetry run python
>>> import colorama
>>> colorama.__version__
'0.4.4'
例えばcoloramaパッケージの次のバージョンである0.4.5が公開された後で新しく参加した開発メンバーが彼のPCに環境を構築するような場合、普通にpip installで最新バージョンをインストールしてしまうと0.4.5がインストールされてしまい、チーム内で使っているcoloramaのバージョンが一致しなくなります。
でもpoetry.lockを共有した状態でpoetry installコマンドを使って環境を構築すると、彼の環境にもバージョン0.4.4のcoloramaがインストールされます。
依存パッケージから削除
もし依存ライブラリを削除したい場合は、poetry removeコマンドを使います。
例えば「よく使うから今回だってきっと必要になるよね」といった理由でnumpyライブラリを依存として追加してしまったものの、結局使わなかった、というような場合でも、次のように1コマンドで依存から除外することができます。
> poetry remove numpy
poetry run pythonなどとした時に使用される仮想環境からも、ちゃんとアンインストールされます。
色付き文字で"hello"と出力してみる
ここからは惰性の話になりますが、せっかくなのでhello()関数を完成させましょう。
# colored_hello/__init__.py
from colorama import init, Fore, Back, Style
__version__ = '0.1.0'
init()
def hello():
print(Fore.RED + Back.GREEN + 'Hello!' + Style.RESET_ALL)
これをpoetry run pythonから実行すると、こんな感じです。
pyproject.tomlの細かな設定
pyproject.tomlを設定するの項では、基本的な部分しか取り上げませんでした。この章ではそこからさらに踏み込んで、実際に一般公開する時に必要な設定を一通り紹介します。
pyproject.tomlの例
僕が公開しているyen-parserというパッケージからpyproject.tomlを抜粋してきました。1項目ずつ説明していきます。
[tool.poetry]
name = "yen-parser"
version = "0.1.0"
description = "Yen currency string parser."
authors = ["kenjimaru <kendimaru2@gmail.com>"]
maintainers = ["kenjimaru <kendimaru2@gmail.com>"]
readme = 'README.rst'
repository = 'https://github.com/kendimaru/yen-parser'
keywords = ['Japanese', 'yen', 'currency', 'parse']
license = "MIT"
classifiers=[
'License :: OSI Approved :: MIT License',
'Programming Language :: Python :: 3.6',
'Programming Language :: Python :: 3.7',
'Programming Language :: Python :: 3.8',
'Programming Language :: Python :: 3.9',
]
[tool.poetry.dependencies]
python = "^3.6"
[tool.poetry.dev-dependencies]
pytest = "^5.2"
[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"
- name
- version
- description
- authors
- maintainers
- readme
- repository
- homepage
- keywords
- license
- classifiers
- [tool.poetry.dependencie]
- [dev-dependencies]
- [build-system]
name
パッケージ名を指定します。ここで指定したパッケージ名は以下の影響を与えます。
- PyPI上での名前
- pip installで指定するパッケージ名
- import パッケージディレクトリ名
ここで指定したパッケージ名が"yen-parser"だとしたら、パッケージディレクトリ名はyen_parserといった感じでハイフンをアンダーバーに置き換えた名前になります。
記述例：
name = "yen-parser"
version
パッケージのバージョンを指定します。
近年広く採用され始めているセマンティックバージョニング方式がオススメです。
セマンティックバージョニングは3つのバージョン情報をドットで区切る方式で、メジャーバージョン・マイナーバージョン・パッチバージョンとして管理する方式です。
この方式についてかなりざっくりした説明をすると、バグフィックスをした場合はパッチバージョンを上げ、機能を追加した場合はマイナーバージョンを上げ、互換性が損なわれる機能変更をした場合はメジャーバージョンを上げる、というものです。
開発版は0.1.0を初版とするのが基本とされています。
記述例：
version = "0.1.0"
description
パッケージの概要情報を記述します。ここに記述した情報はPyPIでパッケージ名の次に表示されます。（画像でいうと左下の部分）
記述例：
description = "Yen currency string parser."
authors
著作権者をリスト形式で記述します。それぞれ"名前 <メールアドレス>"という書式が一般的です。
PyPIではMetaセクションに表示されます。
記述例：
authors = ["kenjimaru <kendimaru2@gmail.com>"]
maintainers
メンテナーをリスト形式で記述します。authorsと同様に、それぞれ"名前 <メールアドレス>"という書式が一般的です。
PyPIではMetaセクションのauthorの下に表示されます。
記述例：
maintainers = ["kenjimaru <kendimaru2@gmail.com>"]
readme
パッケージのREADME情報ファイルを指定します。"README.rst"か"README.md"のどちらかを指定することができます。
PyPIのパッケージページでHTML形式にレンダリングされて表示されます。
記述例：
readme = 'README.rst'
repository
GitHubなどでリポジトリを公開している場合は、そのアドレスを指定します。
PyPIではlinksセクションに表示されます。
記述例：
repository = 'https://github.com/kendimaru/yen-parser'
homepage
公開しているパッケージに専用のWebサイトがあるような場合は、そのアドレスを指定します。（yen-parserは専用Webサイトが無いため指定していません）
PyPIではlinksセクションに表示されます。
homepageの指定が無い場合は、GitHubのリンクに置き換わります。
記述例：
homepage = 'https://example.com'
keywords
プロジェクトと関連しているキーワードを5つまで指定します。
PyPIではMetaセクションに表示されます。
記述例：
keywords = ['Japanese', 'yen', 'currency', 'parse']
license
パッケージを利用する際に適用されるライセンスを指定します。
poetryのサイトでは、次のいずれかのライセンスが推奨となっています。
- Apache-2.0
- BSD-2-Clause
- BSD-3-Clause
- BSD-4-Clause
- GPL-2.0-only
- GPL-2.0-or-later
- GPL-3.0-only
- GPL-3.0-or-later
- LGPL-2.1-only
- LGPL-2.1-or-later
- LGPL-3.0-only
- LGPL-3.0-or-later
- MIT
多いですよね。どれを選択していいか悩むのであれば、この中で僕がオススメするならMITライセンスです。条項がシンプルで洗練された内容になっていて、著作権をきちんと保護するいっぽうで利用者に対する制限も少なく、さらにGitHubで最も採用されているといったライセンスです。
PyPIではMetaセクションに表示されます。
記述例：
license = "MIT"
ちなみにこのライセンスの指定はパッケージを積極的に使ってもらうためにはすごく重要で、ライセンスが指定されていない場合、法的には著作者の許可なく使用することができなかったり、使用している人に対して著作者が後出しで要求したことが正当化されるそうです。利用する側からしたら、ライセンスが明示されてない危険なパッケージは使いませんよね。
classifiers
このパッケージが動作可能なPythonのバージョンや適用されるライセンスなどの情報を指定します。PyPA（Python Packaging Authority＝Pythonパッケージ局？）が定めている部分で、PyPIも記述を推奨しています。
他にもプロジェクトの成熟度（'Development Status'）、想定しているパッケージの利用者、その他もろもろ指定することができますが、最低限必須なのはPythonのバージョンと適用ライセンスです。Pythonバージョンと適用ライセンスの部分は他の項目（lisenceやtool.poetry.dependencies）と重複していて2度も書かせないでくれよって言いたいところですが、どちらも指定しておきましょう。
指定可能な内容はこちらに網羅されています。
記述例：
classifiers=[
'License :: OSI Approved :: MIT License',
'Programming Language :: Python :: 3.6',
'Programming Language :: Python :: 3.7',
'Programming Language :: Python :: 3.8',
'Programming Language :: Python :: 3.9',
]
[tool.poetry.dependencies]
[tool.poetry.dependencies]の中には、依存パッケージの情報を記述します。依存パッケージを追加するの章で実施したように、poetry addコマンドを使って依存パッケージを追加するたびに、poetryがここに情報を追加していきます。逆にpoetry removeコマンドを使って依存パッケージを削除するたびに、対象のパッケージをpoetryがここから削除していきます。
手編集してもいいですが、その際にはパッケージ名とバージョン情報をあらかじめ調べておく必要があります。
記述例：
[tool.poetry.dependencies]
python = "^3.6"
この記述例ではpython = "^3.6"となっているのでpython3.6.0以上のバージョンで動作するが、python4.0.0以降では動作しないということになります。
ここにpoetry add coloramaなどとして依存パッケージを追加すると、既存の依存パッケージの下に追加されていきます。
[tool.poetry.dependencies]
python = "^3.6"
colorama = "^0.4.4"
colorama = "^0.4.4"はバージョン"0.4.4"以上で"1.0.0"未満をサポートするという意味になりますが、バージョン"0.4.4"のみ許可したいといった場合にはcolorama = "0.4.4"とします。
直接pyproject.tomlで編集してもいいし、poetry add colorama@0.4.4として特定のバージョンを指定しつつ追加することもできます。
[tool.poetry.dev-dependencies]
[tool.poetry.dev-dependencies]の中には、開発時に必要になる依存パッケージの情報を記述します。テストツールであるpytestがデフォルトで記述されていますが、こういったものはリリース時には必要無いため、ここに記述されるのが適切です。
その他にもパッと思いつくものとして例を挙げると、ドキュメントを生成するためのsphinxパッケージ、実行ファイルを作成するためのPyInstallerなんかもリリースに含める必要が無いので、もし開発時に使う場合にはこちらに記述することになります。
記述例：
[tool.poetry.dev-dependencies]
pytest = "^5.2"
[build-system]
[build-system]の内容は、特に意識する必要は無くて、pyproject.tomlに初めから記述されている内容をそのまま残しておけば問題ないと思います。（僕もここは触ったことがありません）
記述例：
[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"
あとがき
軽い気持ちで書き始めたこの記事ですが、書き終わってみたら思っていたよりかなり長いものになりました。
自分で書いた記事を読み返しても眩暈がするなと感じるのですが、ここまで辿り着いた方は一体どれくらいいるんだろう？もしかしたらこのあとがきは誰にも読まれる事がないのでは…とさえ思えてきます。もしあなたがここまで到達したのなら、あなたは選ばれし者。何に選ばれたのかについては言及しませんが、とにかく自信を持って、自分のパッケージをどんどん公開していきましょう！
