プロジェクト概要#
Python の実装やパッケージングの領域で最も関連があるプロジェクト群へのまとめとリンク。
PyPA プロジェクト群#
bandersnatch#
bandersnatch は、PyPI をミラーリングするクライアントで、PyPI のコンテンツの完全なコピーを効率よく作成するように設計されています。組織から見ると、これによってパッケージのダウンロードに必要な帯域幅とレイテンシーを (とりわけ自動化されたテストの文脈で) 節約することができ、PyPI のコンテンツデリバリネットワーク (CDN) への負荷を軽減します。ローカルのディレクトリからでも AWS S3 からでもファイル群を提供するようにできます。
ビルド#
build は PEP 517 互換の Python パッケージビルダです。Python API と同様に、パッケージをビルドする CLI を提供します。
cibuildwheel#
説明文書 | 課題リスト | GitHub | PyPI | 議論 | Discord #cibuildwheel
cibuildwheel は、プラットフォーム・ Python バージョン・ CIシステムのよくある組み合わせの全部について wheels をビルドする Python パッケージです。
distlib#
distlib は、 Python ソフトウェアのパッケージングや配布に関係する低レベルの機能を実装しているライブラリです。 distlib はいくつかの関連する PEP (Python Enhancement Proposal standards) を実装していて、サードパーティのパッケージングツールの開発者にとってバイナリやソースコードの 配布物 を作成・アップロードしたり、相互運用性を確保したり、依存関係を解決したり、パッケージリソースを管理したり、その他の類似の機能を実行したりするのに便利です。
近代的な Python パッケージングにおける相互運用性標準に特に気を配って実装された、より厳格な packaging ライブラリ プロジェクト (後述) とは異なり、 distlib は近代的な相互運用性標準ができる前の昔ながらのパッケージやメタデータで今となってはその標準に外れたことになっているものを扱うように言われた時には合理的なフォールバック動作も提供しようとしています。
distutils#
Python の元々のパッケージングシステムで、Python 2.0 の時点で標準ライブラリに追加され 3.12 で削除されました。
パッケージングシステムを維持管理する際の難題には機能向上が言語ラインタイムの更新と密接に結びついていることが挙げられますが、そのせいで distutils を直接に使用することは強い非推奨事項にずっとなり続けてきており、代わりに Setuptools を使うことが望ましいとされています。 Setuptools は、 distutils そのものが提供していない機能 (例えば依存関係の宣言やエントリポイントの宣言) を提供できるだけでなく、守備一貫したビルド用のインタフェイスやサポートするすべてのバージョンの Python のすべてについて設定できる機能を提供しています。
従って、 distutils は PEP 632 によって Python 3.10 で非推奨になり、 Python 3.12 で標準ライブラリから 削除 されました。Setuptools にはスタンドアローンの distutils が同梱されていて、< 3.12 の Python 上であっても setuptools をインポートするか pip を使うと注入されます。
flit#
Flit は、純 Python のパッケージやモジュールを作成して PyPI へアップロードする簡単な手段を提供します。パッケージングに関して 簡単なことを簡単に実現する ことに注力しています。これを使えば単純なプロジェクトやソースコード配布物とwheelsについて素早くセットアップするための設定ファイルを生成し、PyPI にアップロードすることができます。
Flit は、 pyproject.toml を使ってプロジェクトの設定を行います。Flit は、配布物をビルドする Setuptools やそれを PyPI へアップロードする twine のようなツールには依存していません。 Flit は Python 3 を要求しますが、Python 3 上にインポートできるものであれば Python 2 向けのモジュールでも配布することが可能です。
flit パッケージは、2023年10月以来、 tidelift platform でリフト <lift> (訳註、維持管理に対して対価を払うの意か) され、また、PSF に送られたファンドで PyPA 向けに使うように指定された資金を使って、 Matthias Bussonnier によって維持管理されています。
hatch#
Hatch は、 Python での開発者向けに依存関係の管理や環境の分離を便利に行うための統合されたコマンドラインツールです。 Python パッケージ開発者は Hatch とその ビルドバックエンド である Hatchling を使って、パッケージの設定を実施し、バージョン管理を行い、依存関係を指定し、そして PyPI で公開することができます。プラグインシステムがあるので、容易に機能を拡張することができます。
packaging ライブラリ#
(packaging ライブラリには) pip や Setuptools で使われる Python パッケージングのための中核的なユーティリティ (としての core utilities があります)。
packaging ライブラリの core utilities は、バージョンの取り扱い、識別子、マーカ、依存先パッケージ、タグ、その他これに類似した属性やタスクを取り扱います。 Python ユーザのほとんどは、明示的に呼び出す必要に迫られることはなくともこのライブラリに依存しています; ここにリストされているような Python のパッケージングや配布やインストールを扱う他のパッケージを開発する者は、パースしたり検出したりそうでなければ依存関係の属性を取り扱うようなこのライブラリの機能をしばしば利用しています。
このプロジェクトは、 パッケージング仕様 <packaging-specifications で定義された近代的な Python パッケージング相互運用性標準を実装することに焦点を当てており、この標準と互換性が取れないほど古いレガシーパッケージについてエラーを報告します。対照的に、 distlib プロジェクトはもっと寛容なライブラリで、 packaging ライブラリ ならばエラーを報告するような場合であっても曖昧なメタデータをもっともらしく読み込もうと試みます。
pip#
Python パッケージをインストールするに当たっての最もよく知られたツールで、Python の新しめのバージョンには同梱されているもの。
PyPI やその他の Python パッケージインデックスのパッケージを探索・ダウンロード・インストールするための基本的な機能を提供するとともに、コマンドラインインタフェイス (CLI) を通じて広範囲の開発ワークフローに組み込むことができます。
Pipenv#
Pipenv は、全てのパッケージング世界の最良のものを Python 世界に持ち込むことを目的とするプロジェクトです。 Pipfile ・ pip ・ virtualenv を単一のツールチェーンにまとめ上げるものです。 requirements.txt を自動的にインポートすることができ、また、 safety を使って Pipfile 中の CVE を確認することができます。
Pipenv は、ユーザがコマンドラインで環境・依存関係・インポートされたパッケージを管理することを補助することを目的としています。 (他のツールが往々にしてうまく動かない) Windows 上でもきちんと動作し、ファイルのハッシュ値を計算し確認することでハッシュ値による依存関係識別子との互換性を確保し、パッケージの依存関係先のアンインストールを容易にします。
Pipfile#
Pipfile とその姉妹 Pipfile.lock は、 pip における低レベルの requirements.txt ファイルに代わる高レベルのアプリケーション中心のファイルです。
pipx#
pipx は、システムにインストール済みの他のパッケージとの間に依存関係の衝突を起こすことなく Python のコマンドラインアプリケーションをインストールし動作させるためのツールです。
Pythonパッケージユーザーガイド（Python Packaging User Guide）#
このガイド!
readme_renderer#
readme_renderer は、Markdown や reStructuredText のようなマークアップ言語で書かれたユーザ向け説明ファイル (README) を HTML に展開するためにパッケージ開発者が用いるライブラリです。開発者は、リリース管理プロセスの一環として直接または twine 経由でこれを呼び出し、そのパッケージに関する説明がきちんと PyPI に表示されることを確認します。
Setuptools#
(easy_install を含む) Setuptools は Python の distutils への拡張を集めたもので、特に他のパッケージに依存関係がある場合に、より簡単に Python の 配布物 をビルドし配布することが可能となります。
trove-classifiers#
trove-classifiers は、PyPI における分類子 の正統な源泉で、ユーザがそのニーズに即したプロジェクトを PyPI でよりうまく探し出せるように、プロジェクトの保守者が プロジェクトを体系的に表現する のに使います。
trove-classifiers パッケージには、正当な分類子および (それを置き換えた分類子と一組で) 非推奨になった分類子のリストが含まれています。 PyPI にアップロードしようとしているパッケージで使われている分類子の正当性を確認するために、このパッケージを使いましょう。この分類子リストがソースコードの形で公開されているので、それをインストールしてインポートすれば、 PyPI で公開されているリスト を参照するよりももっと便利なワークフローを構築することができます。本プロジェクトの 課題リスト に、提案された分類子に関する議論や新しい分類子が欲しいという要求に関する議論が公開されています。
twine#
Twine は、開発者がパッケージをPython パッケージインデックス (PyPI) や他の Python 用パッケージインデックスへアップロードするのに使う最初の選択肢です。これはコマンドラインプログラムで、プログラムのファイルやメタデータを web API へ渡します。開発者がこれを使うのは、公式の PyPI へのアップロードツールであるからであり、動作が速く安全であるからであり、保守されているからであり、動作が信頼できるからです。
virtualenv#
virtualenv は、 venv と同様に独立した Python 仮想環境 を生成するツールです。 venv とは異なり、virtualenv は PATH 環境変数を使って特定することで他のバージョンの Python 用の仮想環境を作成することができます。他にも、仮想環境の設定・保守・複製・問題解決のための便利な機能を提供しています。より詳しくは、 仮想環境を作って使う の節を見てください。
Warehouse#
現在の Python パッケージインデックス を構成しているコードベース。 pypi.org にホストされています。 pip がダウンロードする際のデフォルトのソースです。
wheel#
wheel は、主として wheel 配布物 を作成するための Setuptools の拡張である bidet_wheel を提供するプロジェクトです。この他にも、wheel ファイルを作成しインストールするためのコマンドラインユーティリティを提供します。
パッケージ開発者がバイナリの wheel フォーマットで開発中の Python パッケージをチェックし問題を解決するためのツールである auditwheel も見てください。このツールは、依存関係を検出し、法令遵守のためのメタデータを確認し、 wheel とメタデータがパッケージないの外部共有ライブラリに正しくリンクしインクルードするように修正する機能を提供します。
非 PyPA プロジェクト#
buildout#
Buildout は Python ベースのビルドシステムで、非 Python ベースのものを含む複数の部品から構成されるアプリケーションの生成・組み立て・配置ができます。buildout の設定を作っておけば、後で同じソフトウェアを再生成することができます。
conda#
conda は、 Python 実装である Anaconda のためのパッケージ管理ツールです。Anaconda Python は、 Anaconda, Inc が特に科学計算の分野に向けて配布している配布物で、とりわけ通常ならバイナリ拡張のインストールが難しいとされる Windows 用に配布しています。
Conda は、 pip や virtualenv や wheel とは全く別のツールですが、パッケージ管理・仮想環境管理・バイナリ拡張のデプロイメントの観点ではこれらのツールを合わせたような機能を提供します。
Conda は PyPI からパッケージをインストールすることはなく、公式の Anaconda リポジトリか、anaconda.org (ユーザが貢献した conda パッケージの置き場所) か、または、ローカル (例えばイントラネット) にあるパッケージサーバからのみインストールすることができます。しかしながら、pip をインストールすることは可能で、PyPI からの 配布物 の管理という点では conda と平行して動作することができます。また、 conda skeleton は、 PyPI から持ってきた Python パッケージのメタデータを修正することで conda がインストールできるものにするためのツールです。
devpi#
devpi は、 PyPI 互換の強力なサーバと PyPI プロクシキャッシュの機能を持っていて、 Python を使ったパッケージングやテスティングやリリース活動を推進するための補完的なコマンドラインツールを備えています。devpi は、また、閲覧と検索が可能なwebインタフェイスも備えています。devpi は、 PyPI のミラーを作成する機能、継承関係を持った複数の パッケージインデックス を扱う機能、これらのインデックスの間の同期機能、インデックスの複製とフェイルオーバとパッケージのアップロードの機能を提供できます。
dumb-pypi#
dumb-pypi は簡潔な パッケージインデックス の静的ファイルのサイトを構築するツールで、パッケージインデックスとして機能するためには静的ファイルをサポートするウェブサーバにホストされていなければなりません。ハッシュ、コアとなるメタデータ、そして yank ステータスをサポートしています。
enscons#
Enscons は、 SCons に基礎を置く Python パッケージングツールです。 C 言語拡張を含む配布物であっても distutils や setuptools を使うことなく pip 互換のソースコード配布物や wheel をビルドすることができます。 Enscons の構造と哲学は distutils のものとは異なります。 Python パッケージングシステムにビルド機能を追加するのではなく、 enscons では汎用のビルドシステムに Python パッケージング機能を追加しています。 Enscons は、 pip で自動的にビルドされた sdist や、enscons から独立した wheel をビルドすることを支援します。
Flask-Pypi-Proxy#
警告
もはや保守されておらず、アーカイブされたプロジェクト
Flask-PyPI-Proxy は PyPI に対するキャッシュ付きのプロクシという形の パッケージインデックス です。
Hashdist#
Hashdist は、非特権ユーザソフトウェアの配布物をビルドするためのライブラリです。 Hashdist は、「Debian 技術が動作していない場合の Debian のような選択肢」になろうとしています。 Python 支持者 (Pythonista) にとっては、 virtualenv と buildout のより強力な混合物が Hashdist だと考えるのが一番でしょう。科学計算分野のソフトウェアをインストールする際の問題を解決し、パッケージ配布物をステートレスでキャッシュ可能かつ分岐可能にすることを目指しています。一部の研究者が使っていますが、2016 年以降は保守されていません。
Maturin#
Maturin は Rust 拡張モジュール用のビルドバックエンドで、Rust で書かれています。Windows ・ Linux ・ macOS および FreeBSD 上で python 3.7+ の wheel をビルドすることができ、それを PyPI にアップロードすることができ、また、 PyPy と GraalPy に対する基本的なサポートもあります。
meson-python#
meson-python は、 Meson ビルドシステムを使うビルドバックエンドです。これによって、 Python パッケージの作者が自分のパッケージ向けに Meson をビルドシステムとして使うことを可能にします。これは C 言語を含む広範囲の言語をサポートしており、最も複雑なビルド設定を記述することが可能になります。
multibuild#
Multibuild は、Linux ・ macOS 向けや (柔軟性は落ちるが) Windows 向けの Python wheels をビルドしテストする一揃いの CI スクリプトです。 cibuildwheel も見てください。
nginx_pypi_cache#
nginx_pypi_cache は、 nginx を用いた パッケージインデックス のキャッシュ機能付きプロクシです。
pdm#
PDM は近代的な Python パッケージ管理ソフトです。 PEP 621 で定義されている形でプロジェクトのメタデータを pyproject.toml に保存します。
pex#
Pex は、 virtualenv を使った独立した Python 環境をに表現した .pex (Python EXecutable) ファイルを生成するためのツールです。 PEX ファイルは、 cp のような単純な Python アプリケーションをデプロイする zipapps です。単独の PEX ファイルで複数のターゲットプラットフォームをサポートすることができ、標準の pip で解決できる要求事項、つまり pex3 lock ... で生成されるロックファイルや別の PEX からであっても作成することができます。 PEX ファイルは、オプションとして PEX ファイルを標準の venv に変換したり依存関係をグラフ化したり、あるいはもっと多くをサポートするツールを内蔵することもできます。
pip-tools#
pip-tools は、Python システムの管理者やリリースマネージャで、特にビルドが必ずできるように保ちたいけれども依存先の新バージョンに追随して最新の状態にもしておきたいという人々のための一揃いのツール群です。ユーザはハッシュ値を与えることで依存先の特定のリリースを指定することや、そのプログラムの他の部分にある情報から適切な書式の requirements を簡単に作成すること、すべての依存先を更新すること (これは現時点の pip にはない機能です) 、プログラムが従うべき制約条件の層を作成することができます。
pip2pi#
pip2pi は、特定のパッケージ群が手動で同期される パッケージインデックス です。
piwheels#
piwheels は、ソースコード配布物パッケージを PyPI から取得して Raspberry Pi 計算機へのインストールに最適化されたバイナリ wheel ファイルにコンパイルするような Web サイトであり、それを支えるソフトウェアです。 Raspberry Pi OS では、 pip が PyPI に加えて piwheel.org を追加のインデックスとして使うように予め設定されています。
poetry#
poetry は、 Python パッケージのビルドやパッケージングに加えて、依存先のインストールや隔離を取り扱うコマンドラインのツールです。 pip に含まれる解決機能に依存する代わりに pyproject.toml を使って自分自身の依存関係解決機能を提供します。依存関係に関するメタデータをローカルにキャッシュすることでインストールや依存関係解決のユーザ体験を高速化しようとしています。
proxpi#
proxpi は、PyPI や他のインデックスをキャッシュ付きでプロクシする単純な パッケージインデックス です。
Pulp-python#
Pulp-python は、 Pulp 向けの Python パッケージインデックス プラグインです。 Pulp-python は、ローカルか AWS S3 にファイルを置くミラー機能や、複数のパッケージインデックスへのプロクシ機能をサポートします。
PyPI クラウド#
警告
もはや保守されておらず、アーカイブされたプロジェクト
PyPI クラウドは、AWS S3 や他のクラウドストレージサービス、あるいはローカルのファイル群で裏打ちされた パッケージインデックス です。PyPI クラウドは、認証や認可と同様に PyPI に対するリダイレクト機能やプロクシ機能をサポートします。
pypiprivate#
pypiprivate は、 パッケージインデックス としてローカルの (または AWS S3 でホストされた) パッケージディレクトリを提供します。
pypiserver#
pypiserver は、単純な API とブラウザ向けのインタフェイスだけを実装した (ローカルディレクトリ上の) 組織内部向けプライベート Python パッケージインデックス として振る舞う「小さいことは良いことだ」主義者のアプリケーションです。公衆向けに公開することなく標準のツールを使って外部非公開のパッケージをアップロードすることもできますし、それを pip でダウンロード・インストールすることもできます。 pypiserver を用いる組織では、通常は pypiserver と PyPI の両方からパッケージをダウンロードします。
PyScaffold#
PyScaffold は、Python パッケージが PyPI で共有できて pip でインストールできるように初期設定を行うプロジェクトジェネレータです。定評のあるツール (Setuptools や pytest や Sphinx) 用に穏当なデフォルト設定を与えることで、開発者がすぐにコードを書き始められるような生産的な環境を提供します。 PyScaffold は、また、既存のプロジェクトにおいてもパッケージングをより簡単にするために使用することができます。
pywharf#
警告
もはや保守されておらず、アーカイブされたプロジェクト
pywharf は、ローカルから、もしくは GitHub からファイルを提供する パッケージインデックス です。
scikit-build#
Scikit-build は、C/C++/Fortran/Cython で書かれた拡張をビルドする CPython のための Setuptools ラッパです。追加のコンパイラやビルドシステムやクロスコンパイルに対するより良いサポートを提供するため、また、関連するビルドで要求されるライブラリなど <build requirements> の位置を特定するために cmake (PyPI にあります) を使用します。大きなプロジェクトのビルドの速度を増したり並列化したりするために、ユーザは `ninja <https://pypi.org/project/ninja>`___ (これも PyPI にあります) をインストールすることができます。
scikit-build-core#
Scikit-build-core は、CPython C/C++/Fortran/Cython による拡張モジュールのためのビルドバックエンドです。追加のコンパイラやビルドシステムやクロスコンパイル、また、依存関係とそれに付随するビルド時の要求事項を解決する点でより良いサポートを提供するために、ユーザが cmake (PyPI から利用可能) を使って拡張を書くことができるようにします。 CMake/Ninja は、もしシステム上に利用可能なものがなければ、 PyPI から自動的にダウンロードされます。
shiv#
shiv は、 PEP 441 に概要が示されている完全自己完結型 Python zipapp であるが必要な依存先をすべて内包したものをビルドするためのコマンドラインユーティリティです。このツールの第一の目標は、Python アプリケーションとコマンドラインツールを素早く簡便に配布できるようにすることです。
simpleindex#
simple index は、 URL を (PyPI を含む) 複数のパッケージインデックスに振り分け、ローカルの (または、カスタムプラグインを使って例えば AWS S3 のようなクラウドにホストされた) パッケージディレクトリからファイルを提供し、カスタムプラグインをサポートしている パッケージインデックス です。
Spack#
(spack は) 複数のバージョン・設定・プラットフォーム・コンパイラをサポートするように設計された自由度の高いパッケージマネージャです。 Spack は Homebrew に似ていますが、Python で書かれていてコンパイラやライブラリのバージョン、ビルドオプションなどが簡単に入れ替えることができるようにパラメータ化されています。同一のシステムの中に任意のバージョンのパッケージをいくつも同居させることができます。 Spack は、元々はクラスタ構成のコンピュータ群やスーパーコンピュータの上で科学分野の高パフォーマンスアプリケーションを素早くビルドするために設計されました。
Spack は (まだ) PyPI にありませんが、 GitHub からクローンした直後にインストール作業なしで使用できます。
zest.releaser#
zest.releaser は、 twine の上に抽象レイヤを提供する Python パッケージのリリースツールです。 Python 開発者は zest.releaser を使ってパッケージバージョンを増加させたり、変更履歴 (Changelog) を更新したり、ソースコード管理の側でリリースタグを挿入したり、新しいパッケージを PyPI にアップロードすることを自動化することができます。
標準ライブラリ内のプロジェクト群#
ensurepip#
このパッケージはPython の標準ライブラリ内のパッケージで、既存のインストール済み Python 環境や仮想環境に pip を組み込むためのサポートを提供します。ほとんどの場合にはエンドユーザがこのモジュールを使うことはなく、どちらかと言えば Python 配布物のビルドの際に使われるでしょう。
http.server#
ウェブサイトとして、つまり例えば パッケージインデックス として、ディレクトリを扱うことができるパッケージとコマンドラインインタフェース (自分用のシンプルなリポジトリをホストする を参照してください) 。
venv#
(Python 3.3 から始まる) Python の標準ライブラリに存在する 仮想環境 を生成するためのパッケージ。更なる情報については 仮想環境を作って使う を見てください。