「Pythonプロジェクトを保護する：究極のコードセキュリティのために直接setup.pyの呼び出しを避ける！」

Pythonプロジェクトのコードセキュリティを向上させる方法

setup.pyの複雑さにさようならを告げ、ビルドフロントエンドを使った効率的なPythonパッケージングに取り組む時が来ました。

この記事では、distutilsやsetuptoolsが直接setup.pyを使用する場合の課題について探求し、もはや最善のアプローチではないことを説明します。DistutilsとSetuptoolsはかつて重要でしたが、setup.pyを直接実行する場合には制約がありました。Distutilsにはモダンな機能が不足しており、Setuptoolsには複雑さと移植性の課題がありました。

そのアプローチを変え、setuptoolsチームはコマンドラインインターフェースの提供から離れ、パッケージ作成用のライブラリに焦点を当てています。この変更は、setuptoolsが廃止されることを意味するのではなく、setup.pyファイルの直接実行を避けるべきということです。

pipやPoetryなどの依存性管理ツールを使用することで、パッケージのビルドとインストールプロセスを自動化できます。そのシンプルさ、移植性、将来性の利点を活かすことで、現代のPythonパッケージングの成功の鍵となります。

従来、setup.pyはPythonパッケージングの入り口として機能していました。開発者はプロジェクトのメタデータ、依存関係、およびインストール手順を定義するためにそれに頼っていました。スクリプトの呼び出しはpython setup.py installを実行するだけで簡単であり、Pythonプロジェクトをパッケージ化するための事実上の方法のように思われました。

• LayoutLMv3を使用してビジネス文書から主要な情報を抽出する方法
• アドビエクスプレスは、Firefly Generative AIを使用してユーザーエクスペリエンスを向上させています
• プロンプトアンサンブルはLLMをより信頼性のあるものにします

しかし、物語はそこで終わりません。個人的な体験談はしばしば、setup.pyに完全に頼ることの制約や特異性を明らかにします。多くの開発者のように、私もdistutilsとsetuptoolsを使用しているプロジェクトで依存関係の競合やバージョンの非互換性による混乱の渦に巻き込まれることがありました。あるライブラリの更新が予期しないエラーの連鎖を引き起こすため、影を追いかけているような感じがしました。

「my_package」というパッケージを「my_module.py」という単純なモジュールを持つようにビルドすると想像してみてください。昔ながらのアプローチでは、パッケージングの過程は次のようになっていたかもしれません:

# setup.pyfrom distutils.core import setup

setup(    name='my_package',    version='1.0',    py_modules=['my_module'],    # その他のメタデータ...)

何の問題もなさそうですよね？しかし、プロジェクトが複雑になるにつれて、distutilsの制約が明らかになり、このアプローチでは依存関係の管理や自動インストールなどの多くの高度な機能が欠けています。

Setuptoolsは高度な機能と依存関係の管理を約束して登場しました。setuptoolsはdistutilsよりも改良されていますが、よりモダンなパッケージングツールによる置き換えのために廃止されつつあります。

もっと複雑なプロジェクトで外部の依存関係と追加のメタデータが必要な場合を考えてみましょう:

# setup.pyfrom setuptools import setup

setup(    name='my_package',    version='1.0',    packages=['my_package'],    install_requires=[        'requests',        'numpy',    ],    # その他のメタデータ...)

Setuptoolsは当初、パッケージの配布の合理化、依存関係の管理、メタデータの強化といった機能でPythonの開発を改善しました。distutilsとsetuptoolsの両方に対してpython setup.py sdistを実行すると、ソースディストリビューションが作成されました。しかし、Pythonが進化するにつれて、制約も現れました:

1. グローバルなインストールの競合: Setuptoolsは異なる依存関係のバージョンをグローバルにインストールすることで競合が発生し、プロジェクト間の互換性の問題を引き起こしました。
2. 複雑さと保守性: プロジェクトが成長するにつれて、setup.pyファイルの管理が複雑になり、プロジェクト全体での更新が必要になり、開発が遅くなりました。
3. 分離と再現性: Setuptoolsはプロジェクトの依存関係を分離することに苦労し、システム間で一貫した環境を作ることが難しくなりました。
4. 標準化の欠如: Setuptoolsにはプロジェクトの構造や設定形式の標準化がなく、プロジェクトの組織に分散を引き起こしました。

しかし、setuptoolsの注目すべき欠点は、異なるプラットフォームや環境での依存関係の解決の一貫性の欠如です。この一貫性の欠如は、異なるシステムにパッケージをインストールしようとする際に問題が発生することがよくあります。これらの問題に対処するための代替手段として、ビルドフロントエンドとバックエンドの使用があります。

setuptoolsなどの従来のアプローチによって引き起こされる課題は、PEP 518とPEP 517の導入、およびpyproject.tomlファイルの採用によって解決されました。PEP 518とPEP 517は、ビルドフロントエンドとバックエンドの分離という注目すべき進歩をもたらしました。これにより、開発者は必要に応じて簡単にビルドツールを切り替えることができます。たとえば、ローカル開発、テスト、または本番ビルドには異なるツールを使用することができます。

複雑な setup.py ファイルをひとつの中央集権的な場所で管理する代わりに、プロジェクトの設定、依存関係、およびビルド設定をすべて pyproject.toml ファイルで管理します。この単一のファイルがコマンドセンターとなり、プロジェクトの管理が簡単になります。

[tool.poetry]name = "my_package"version = "1.0"[tool.poetry.dependencies]python = "^3.6"requests = "^2.25"numpy = "^1.20"[build-system]requires = ["poetry-core>=1.0.0"]build-backend = "poetry.core.masonry.api"

ここでは、設定は整理されて表現力があります。依存関係はバージョン範囲で定義されており、柔軟性と互換性が保証されています。 [build-system] セクションは魔法の場所です。 [tool.poetry] セクションはプロジェクトのメタデータと依存関係を定義し、 [build-system] セクションはビルドバックエンドを指定します。ビルドバックエンドはビルドプロセスの実行を担当します。

パッケージを構築する準備ができたら、 ’poetry build’ コマンドだけで済みます。

Python パッケージングツールの旅はかなりのものでした。昔は、distutils と setuptools が主役で、その時代のニーズに最善を尽くしていました。しかし、ソフトウェア開発の世界が進化するにつれて、彼らはやや手に負えなくなりました。

Poetry は依存関係の複雑なウェブを単純化するだけでなく、プロジェクトの非常に核となる部分を強化するものです。それは、プロジェクトの基盤をより堅牢で将来に対応したものにするための追加の層と考えてください。

ですので、distutils と setuptools が彼らの時代のスターだったのに対し、舞台は今や poetry とその仲間たちに属しています！

お読みいただきありがとうございます！この投稿がお役に立てたことを願っています。さらに詳しく知りたい場合は、このディスカッションの基礎となった 記事 をご覧ください。また、私の最新の作業については、 LinkedIn または VoAGI でつながることもできます。

次回まで、Anushka！

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!