ستساعدك المقالة التالية: Python و Multi-CPU-Arch – نحو الذكاء الاصطناعي
نُشر في الأصل على نحو AI ، الشركة الرائدة في العالم في مجال الذكاء الاصطناعي والأخبار التقنية والإعلام. إذا كنت تقوم ببناء منتج أو خدمة متعلقة بالذكاء الاصطناعي ، فنحن ندعوك للتفكير في أن تصبح راعيًا للذكاء الاصطناعي. في نحو الذكاء الاصطناعي ، نساعد في توسيع نطاق الشركات الناشئة في مجال الذكاء الاصطناعي والتكنولوجيا. دعنا نساعدك على إطلاق التكنولوجيا الخاصة بك للجماهير.
إصلاح أعطال سلسلة أدوات Python على نظام التشغيل Mac M1 / M2 بشكل موثوق
مقدمة
يتمثل أحد أهداف تصميم Python في أن تكون محايدًا للنظام الأساسي وأن تقوم بتشغيل البرامج النصية دون تعديل عبر البيئات. تقوم Python بعمل جيد جدًا في ضمان هذا التوافق طالما أن التطبيقات والمكتبات مكتوبة باستخدام برامج Python النصية. مع ازدياد شعبية Python وتكيفها ، بدأت المزيد والمزيد من المكتبات في استخدام امتدادات Python لتضمين التعليمات البرمجية المتوافقة محليًا لتعزيز الأداء والكفاءة. يمكن لمكتبات python الشهيرة مثل pandas و NumPy التعامل مع كميات كبيرة من البيانات بكفاءة بفضل امتدادها الأصلي. نظرًا لأن المزيد والمزيد من مكتبات Python بدأت في استخدام التعليمات البرمجية المطابقة محليًا ، بدأت مشكلات توافق النظام الأساسي في الظهور في بيئات Python. إذا كان أحد يستخدم أجهزة MacBooks القائمة على Mx (M1 / M2) ، فمن المحتمل جدًا أن يكون قد شهد مشكلات توافق النظام الأساسي في بيئة بيثون. تتحدث هذه المقالة عن كيفية قيام مدير مكتبة Python مثل pip و conda بإدارة الثنائيات المعتمدة على النظام الأساسي ، ولماذا تتعطل ، وكيفية تجاوزها على إعدادات Mac M1 / M2 بطريقة أبسط وأكثر موثوقية وقابلة للتكرار.
يتم تجميع ثنائيات Python ، مثل أي ثنائي آخر ، بشكل منفصل لبنى ومنصات وحدة المعالجة المركزية المختلفة (Windows/ ماك / لينكس). عندما يقوم Python بتثبيت مكتبة Python في نظام ما ، فإنه يقوم بجمع ومعالجة البيانات الوصفية الخاصة بوحدة المعالجة المركزية والنظام الأساسي المحلي. إذا كانت مكتبة python تتضمن أي ملحقات أصلية ، فيجب تجميعها في وحدة المعالجة المركزية وثنائي خاص بالنظام الأساسي لتشغيلها محليًا. سيساعد الفهم الموجز لكيفية إدارة مديري حزم Python مثل “PIP” و “conda” على تبعيات وحدة المعالجة المركزية والنظام الأساسي في فهم أوجه القصور فيها وكيفية التغلب عليها.
دعم PIP متعدد القوس
يستخدم PIP معيار التعبئة “العجلة” لتوزيع حزم بيثون. ‘Wheel’ هو نظام تغليف لتعبئة نصوص Python النقية والإضافات الأصلية في كل من التعليمات البرمجية المصدر والصيغة الثنائية المجمعة. للحصول على منظور أفضل حول كيفية احتفاظ PIP بتنسيقات توزيع مختلفة ، قم بزيارة صفحة ويب “pip” لمكتبة من اختيارك وانقر على “تنزيل الملفات”. في هذه الصفحة ، يسرد قسم “توزيع المصدر” الحزم المتوفرة في تنسيق المصدر ، ويسرد قسم “التوزيعات المبنية” جميع الحزم المتوفرة في التنسيقات الثنائية سابقة الإنشاء. على سبيل المثال ، يعرض رابط الصفحة هذا المصدر والتوزيعات المعدة مسبقًا لمكتبة “الباندا”. تتبع حزم التوزيع هذه اصطلاح تسمية كما هو محدد أدناه.
{dist} – {version} (- {build})؟ – {python} – {abi} – {platform} .whl
كل قسم في {brackets} هو علامة أو مكون من اسم العجلة يحمل بعض المعاني حول ما تحتويه العجلة والمكان الذي ستعمل فيه العجلة أو لا تعمل. مثال:
الباندا-1.5.0-cp311-cp311-macosx_11_0_arm64.whl
الباندا – هو اسم المكتبة
1.5.0 – هو إصدار المكتبة
cp11 – الحد الأدنى المطلوب من إصدار python
cp11 – الحد الأدنى للواجهة الثنائية للتطبيق (ABI) مطلوب
macosx_11_0_arm64 – علامة النظام الأساسي التي تنقسم مرة أخرى إلى ما يلي:
– macosx – نظام التشغيل
– 11_0 – الحد الأدنى المطلوب لإصدار MacOS SDK
– arm64 – هندسة وحدة المعالجة المركزية
يدعم اصطلاح تسمية PIP أيضًا “wildcard” لتحسين حزم الحزم. على سبيل المثال ، يدعم “chardet-3.0.4-py2.py3-none-any.whl” كلاً من python2 و python3 ولا يعتمد على ABI ، ويمكن تثبيته على أي نظام أساسي وبنية وحدة المعالجة المركزية. تستخدم العديد من مكتبات python خيارات أحرف البدل هذه لتحسين عدد حزم الحزم. لمزيد من المعلومات حول عجلة Python و PIP ، يرجى الرجوع إلى ما هي عجلات Python ولماذا يجب أن تهتم؟
لماذا فشل تثبيت PIP؟
في معظم الأحيان ، يفشل تثبيت PIP لسببين رئيسيين. أولاً ، إذا كانت المكتبة سابقة الإنشاء غير متوفرة في المستودع ، فسيقوم PIP بتجميع كود مصدر الامتداد الأصلي على النظام المضيف. للقيام بذلك ، من المتوقع أن تكون أدوات البناء والمكتبات التابعة الأخرى متاحة على المضيف. في بعض الأحيان يصبح هذا تحديًا لتثبيت تبعيات البناء محليًا ، خاصةً عندما تنمو شجرة التبعية بعمق.
ثانيًا ، بسبب “wildcard” في أسماء حزم العجلة. قدم MacBook بنية وحدة المعالجة المركزية “M1 / M2” القائمة على الذراع مؤخرًا. تم إدراج بعض حزم العجلات القديمة لنظام التشغيل macOS على أنها “أي” لبنية وحدة المعالجة المركزية لأن x86 كان الهيكل الوحيد المدعوم بحلول ذلك الوقت. إذا حل PIP تبعية الحزمة إلى أحد هذه الإصدارات القديمة ، فسيقوم PIP بتثبيت هذه الحزمة على بنية وحدة المعالجة المركزية الأحدث ، بافتراض أنها ستعمل. مثال على هذه المشكلة هو الحزمة “azure-eventhub”. هذه المكتبة تابعة لمكتبة أخرى تسمى “uamqp”. تسرد هذه المكتبة حزمة شاملة / شاملة لنظام macOS غير متوافقة مع معالج M1 / M2 arm64. إذا قمت بتثبيت ‘azure-eventhub’ على M1 / M2 ، سيرى المرء أن الحزمة سيتم تثبيتها بنجاح ولكنها ستطرح استثناء وقت التشغيل أثناء استيراد هذه الحزمة.
دعم Conda Multi-Arch
تأخذ Conda خطوة أخرى إلى الأمام في ضمان إمكانية نقل النظام الأساسي. لا تقتصر حزم Conda على مكتبات Python فحسب ، بل تشمل أيضًا المكتبات التابعة والثنائيات والمترجمين ومترجمي Python لأنظمة التشغيل المختلفة وبنية وحدة المعالجة المركزية. بهذه الطريقة تضمن أن تكون سلسلة الأدوات بأكملها محمولة عبر البيئات. نظرًا لأن جميع الثنائيات التابعة يتم حزمها أيضًا مع مكتبات Python ، فإنها لا تتوقع أي تبعيات على النظام المحلي باستثناء مكتبات C القياسية. لذا ، إذا كانت conda توفر قابلية نقل أفضل وأصلحت أوجه القصور في PIP ، فما الخطأ الذي يمكن أن يحدث؟ المشكلة ليست كل حزم Python متوفرة في Conda. من الشائع استخدام pip داخل بيئة conda لتثبيت حزم python غير المتوفرة في conda ؛ ومن ثم ، يتعرض المرء لأوجه القصور في PIP. مرة أخرى (وليس nitpick) حزمة ‘azure-eventhub’ هي مثال على ذلك.
إذا واجه المرء مشكلة توافق النظام الأساسي هذه وعند البحث عن حلول في المنتديات ، فسيواجه المرء خيارات مختلفة مثل تثبيت إصدار معين من Python أو مكتبة ، أو تثبيت المكتبة عبر أنظمة تعبئة أخرى مثل “الشراب” أو تثبيت حزم بديلة ، إلخ. العديد من هذه الإصلاحات غير موثوقة للإنتاج وقد لا تكون قادرة على التكرار عبر الأنظمة الأخرى. يوجد أدناه ثلاثة خيارات هي طرق أبسط وموثوق بها وقابلة للتكرار للتغلب على مشكلات توافق نظام Python. هم:
- تثبيت Pip من المصدر
- كوندا وروزيتا
- بناء Docker Multi-Arch
تثبيت Pip من المصدر
إذا كانت تبعيات بناء الكود الأصلي للحزمة ضئيلة ، فيمكن إعادة تجميعها على النظام المضيف. عندما يفشل تثبيت سلسلة أدوات python (مكتبات) ، على الأرجح ، لن تكون حزمة المستوى الأعلى هي التي قد تنكسر بل حزمة تابعة متداخلة في شجرة التبعية. يمكن للمرء استخدام الأمر التالي لإرشاد النقطة بعدم تثبيت الإصدار الثنائي من الحزمة. على سبيل المثال ، سيتخطى الأمر التالي إصدار النقطة الثنائية من “uamqp” ويجمعها من المصدر.
تثبيت نقطة – لا ثنائي uamqp azure-eventhub
كوندا وروزيتا
طريقة أخرى للتغلب على هذه المشكلة هي الاستفادة من “رشيد”. أبسط خيار لتشغيل الإصدار x86 من python عبر Rosetta هو استخدام خيار تجاوز نظام conda الأساسي. مثال
CONDA_SUBDIR = osx-64 conda create -n myenv_x86 python = 3.10
conda تفعيل myenv_x86
conda config –env – اضبط subdir osx-64 # قم بتكوينه باستخدام إصدار النظام الأساسي x86_64 من python
python -c “منصة استيراد ؛ طباعة (platform.machine ())”
يتجاوز متغير البيئة “CONDA_SUBDIR” بنية وحدة المعالجة المركزية لـ conda أثناء تنفيذ أمر إنشاء بيئة conda. يتجاوز الأمر conda config بنية وحدة المعالجة المركزية في البيئة الجديدة طوال الوقت بحيث لا يحتاج المرء إلى تعيين “CONDA_SUBDIR” لجميع الأوامر الأخرى في تلك البيئة. بعد إنشاء بيئة جديدة باستخدام نظام conda الأساسي الذي تم تجاوزه إلى x86 ، فإنه يتصرف مثل أي بيئة conda أخرى. يمكن للمرء إجراء تثبيت PIP في هذه البيئة ، وسيقوم بتثبيت الإصدار x86 من مكتبات python. يعد التبديل بين بيئات conda المتعددة سلسًا في نفس الجهاز ، وحتى الأدوات الأخرى مثل VS Code تعمل بسلاسة دون أي مشاكل.
Docker Multi-Arch
الخيار الثالث هو الاستفادة مرة أخرى من Rosetta ولكن عبر “عامل الإرساء”. هذا هو الخيار الأكثر قابلية للنقل والسلاسة للعمل عبر بيئات ومستخدمين متعددين. يمكن استخدام ميزة Docker Multi-Platform لفرض إنشاء صور عامل إرساء x86 على أجهزة MacBooks M1 / M2. عندما يتم تقديم تشغيل عامل الإرساء مع صورة عامل إرساء x86 ، فإنه يستخدم داخليًا Rosetta لتشغيل الصورة. فيما يلي خطوات إنشاء صورة x86 متعددة المنصات.
من أوبونتو
قم بتشغيل apt-get update
قم بتشغيل apt-get install -y python3
CMD [“/usr/bin/python3”, “-c”, “import platform; print(\”Platform:\”, platform.machine())”]
بناء عامل ميناء – منصة لينكس / amd64 . -t img_x86
تشغيل عامل ميناء $ – منصة لينكس / amd64 -إنه img_x86
النظام الأساسي: x86_64
للحصول على إمكانية نقل أفضل عبر العديد من المستخدمين والبيئات ، يمكن استخدام خيار “النظام الأساسي” في الأمر FROM الخاص بـ Dockerfile. يضمن ذلك استخدام صورة x86 حتى إذا لم يحدد المستخدم خيار “- platform” لأمر الإنشاء.
من – النظام الأساسي = لينكس / amd64 تحديث ubuntu RUN apt-get
قم بتشغيل apt-get install -y python3
CMD [“/usr/bin/python3”, “-c”, “import platform; print(\”Platform:\”, platform.machine())”]
سيقوم ملف عامل الإرساء هذا ببناء صورة عامل إرساء x86 بدون خيار إنشاء عامل ميناء “- platform”.
بناء عامل ميناء. -t img_x86
تشغيل docker $ img_x86
النظام الأساسي: x86_64
خاتمة
قد لا تكون الخيارات المذكورة أعلاه هي الطريقة الوحيدة لإصلاح مشكلات توافق منصة Python بشكل موثوق ، لكنني أعتقد أنها ستكون بمثابة نهج عام لا يحتاج إلى تفكير للكثيرين منا للتغلب بسرعة على مثل هذه المشكلات وتجنب الإحباط وتوفير الوقت في البحث عن مخصص حل. نأمل أن يتطور نظام Python البيئي في المستقبل القريب وينضج بشكل أكبر للتعامل مع وحدات المعالجة المركزية والأنظمة الأساسية المتعددة بسلاسة دون أي تدخل إضافي من المستخدم.
نُشر Python و Multi-CPU-Arch في الأصل في Towards AI on Medium ، حيث يواصل الأشخاص المحادثة من خلال تسليط الضوء على هذه القصة والرد عليها.
تم النشر عبر نحو الذكاء الاصطناعي
