إتقان حزم بايثون: دليل حديث للتوزيع

بالنسبة للعديد من مطوري بايثون، يعد كتابة الكود الجزء السهل. تبدأ التحدي الحقيقي عندما تحتاج إلى مشاركة هذا الكود مع العالم أو التأكد من تثبيت مشروعك بشكل متسق عبر بيئات مختلفة. شهد تجميع بايثون تطوراً كبيراً في السنوات الأخيرة، حيث انتقل من الممارسات المجزأة في الماضي نحو نظام بيئي موحد وقوي. سواء كنت تبني مكتبة لـ PyPI أو تدير التبعيات لتطبيق داخلي معقد، فإن فهم الأدوات الحديثة أمر ضروري للتطوير المهني.

التحول من setup.py إلى pyproject.toml

تاريخياً، كان setup.py هو العمود الفقري لحزم بايثون. ومع ذلك، كان لديه عدة قيود: حيث يمكن أن يحتوي على كود تنفيذي تعسفي، مما يجعله خطراً أمنياً، ويفتقر إلى طريقة إعلانية لتعريف التبعيات المعقدة لبناء المشروع. عالجت مجتمع بايثون هذه المشكلات من خلال PEP 518 و PEP 621، مقدّمين ملف pyproject.toml كمصدر وحيد للحقيقة لبيانات المشروع وتكوين البناء.

اليوم، يجب أن يكون ملف pyproject.toml الحديث بسيطاً وإعلانياً في آن واحد. فهو يحدد اسم مشروعك، والإصدار، والتبعيات، والخلفية (backend) للبناء التي ترغب في استخدامها. فيما يلي مثال قياسي لمشروع يستخدم 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، تضمن أن برمجياتك تلبي معايير الجودة والأمان الحديثة. مع استمرار تطور مشهد بايثون، سيظل البقاء على اطلاع حول PEPs وأفضل الممارسات يجعل استراتيجيات التوزيع الخاصة بك فعالة ومستقبلية.