برای بسیاری از توسعهدهندگان پایتون، نوشتن کد بخش آسان ماجراست. چالش واقعی زمانی آغاز میشود که نیاز به اشتراکگذاری آن کد با جهان یا اطمینان از نصب یکپارچه پروژه در محیطهای مختلف دارید. بستهبندی پایتون در سالهای اخیر تحول چشمگیری داشته و از روشهای پراکنده گذشته به سمت اکوسیستمی استاندارد و مستحکم حرکت کرده است. چه در حال ساخت کتابخانهای برای PyPI باشید و چه در حال مدیریت وابستگیها برای یک برنامه داخلی پیچیده، درک ابزارهای مدرن برای توسعه حرفهای ضروری است.
گذار از setup.py به pyproject.toml
به طور تاریخی، setup.py ستون فقرات بستهبندی پایتون بود. با این حال، این روش دارای چندین محدودیت بود: میتوانست شامل کدهای اجرایی دلخواه باشد که آن را به یک ریسک امنیتی تبدیل میکرد و فاقد روشی اعلانی (declarative) برای تعریف وابستگیهای ساخت پیچیده بود. جامعه پایتون با PEP 518 و PEP 621 این مشکلات را برطرف کرد و فایل pyproject.toml را به عنوان تنها منبع حقیقت برای متادیتا و پیکربندی ساخت پروژه معرفی نمود.
امروزه، یک pyproject.toml مدرن باید حداقلی و در عین حال اعلانی باشد. این فایل نام پروژه، نسخه، وابستگیها و بکاند ساخت مورد نظر شما را تعریف میکند. در زیر یک نمونه استاندارد برای پروژهای که از setuptools به عنوان بکاند استفاده میکند، آورده شده است:
[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"
[project]
name = "my-advanced-lib"
version = "0.1.0"
description = "A modern Python library example"
readme = "README.md"
license = {text = "MIT"}
requires-python = ">=3.8"
authors = [
{name = "Dev Name", email = "dev@example.com"}
]
dependencies = [
"requests>=2.28.0",
"click>=8.0"
]
[project.optional-dependencies]
dev = [
"pytest>=7.0",
"black>=22.0"
]
انتخاب بکاند ساخت مناسب
در حالی که setuptools همچنان بکاند پیشفرض در بسیاری از ابزارهاست، تنها گزینه موجود نیست. جایگزینهای مدرن مانند Hatchling و Flit زمانهای ساخت سریعتر و پیکربندیهای سادهتری ارائه میدهند. Hatchling به ویژه در حال کسب محبوبیت است زیرا برای سرعت و قابلیت اطمینان طراحی شده و بسیاری از پیچیدگیهای قدیمی setuptools را حذف میکند.
هنگام انتخاب یک بکاند، پیچیدگی پروژه خود را در نظر بگیرید. اگر بستههای خالص پایتون ساده را توزیع میکنید، Flit یا Hatchling گزینههای عالی هستند. اگر به شدت به ابزارهای قدیمی یا اکستنشنهای پیچیده C وابسته هستید، setuptools ممکن است همچنان ضروری باشد. صرفنظر از بکاند، نکته کلیدی این است که پیکربندی خود را اعلانی نگه دارید.
توزیع به صورت Wheel
هنگام توزیع کد خود، باید هدف خود را بر تولید "wheels" (فایلهای .whl) متمرکز کنید. برخلاف توزیعهای منبع (sdist) که نیاز دارند سیستم کاربر بسته را در حین نصب کامپایل کند، wheelها باینریهای از پیش ساخته شده هستند. این موضوع زمان نصب را به طور قابل توجهی کاهش میدهد و از خطاهای ساخت ناشی از کتابخانههای سیستمی یا کامپایلرهای گمشده جلوگیری میکند.
برای ساخت یک wheel، معمولاً از ابزاری مانند build استفاده میشود. این یک ابزار خط فرمان مستقل است که بکاند ساخت شما را در بر میگیرد:
python -m build
این دستور یک دایرکتوری dist/ ایجاد میکند که شامل هر دو حالت sdist و wheel است. فایل wheel دارای یک قرارداد نامگذاری خاص است که نسخه پایتون، ABI و پلتفرم را کدگذاری میکند و اطمینان حاصل میشود که pip نسخه صحیح را برای کاربر نصب میکند.
آپلود به PyPI
پس از ساخته شدن بسته شما، مرحله نهایی توزیع است. برای بستههای عمومی، این معمولاً به معنای آپلود در فهرست بستههای پایتون (PyPI) است. ابزار توصیه شده برای این کار twine است. این ابزار آپلودهای امن و تأیید شده را فراهم میکند و متادیتای شما را برای خطاهای رایج قبل از ارسال بررسی میکند.
همیشه بسته خود را ابتدا در TestPyPI آزمایش کنید. این نمونه ایزوله به شما اجازه میدهد فرآیند آپلود را بدون تأثیر بر مخزن اصلی تأیید کنید. دستور آن ساده است:
twine upload --repository testpypi dist/*
نتیجهگیری
تسلط بر بستهبندی پایتون تنها پیروی از قواعد نحو نیست؛ بلکه درک اکوسیستمی است که به کد شما اجازه میدهد به طور قابل اعتماد به اشتراک گذاشته، نصب و نگهداری شود. با اتخاذ pyproject.toml، انتخاب بکاندهای ساخت مناسب و توزیع به صورت wheel، اطمینان حاصل میکنید که نرمافزار شما با استانداردهای مدرن کیفیت و امنیت مطابقت دارد. با ادامه تحولات در منظره پایتون، آگاه ماندن درباره PEPها و بهترین شیوهها، استراتژیهای توزیع شما را موثر و آیندهنگرانه نگه میدارد.