بيثون الفوضى التبعية

هل أنت على دراية بتاريخ التعبئة والتغليف بيثون؟ هل تتنقل في صيغ الحزمة؟ هل تعلم أنه سيتعين عليك كشف تشابك التبعيات حتى عندما تبدو وكأنها معجزة - لا تعتمد على الصفر؟ أنا متأكد من أنهم ليسوا على دراية بكل هذا مثل مؤلف مكتبة DepHell.



تمكنت من التحدث مع نيكيتا فورونوف ، المعروف باسم Gram أو orsinium ، وأسأله عن موضوع تقرير مستقبلي ، وآلام حلول حل التبعية السيئة ، و DepHell ، و pip ، والمبدأ الأول للفوز بالمطابقة ، و Guido ، و Pipfile ، و Python ، التطوير التدريجي ومستقبل النظام البيئي.

- في Moscow Python Conf ++ ، ستتحدث عن التبعيات وكل شيء بجوارها. لماذا اخترت هذا الموضوع فقط للتقرير؟

لأن هذا السؤال يمر بكل تجربتي مع بيثون. عندما قدمت الحزمة الأولى ، كتبت الرمز الأول ، فكرت في كيفية مساعدة الآخرين حتى يتمكنوا من تثبيته ، وقاموا بـ setup.py. ثم عمل في شركة ، في شركة أخرى ، في شركة ثالثة ، كانت المهمة معقدة ومتطورة. في البداية كان هناك فقط ملف requirements.txt ، ثم أدركت أنني بحاجة لإصلاح التبعيات وأدوات النقطة ، حيث ظهر ملف القفل. في وقت لاحق حصلنا على Pipenv ، ثم الشعر.

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

- الألم هو دائما للاهتمام. ما رأيك هي المشاكل الآن في هذا الجزء من بيثون؟

لدى JS دليل node_modules ، ولكل تبعية تبعية خاصة بها مكدسة بداخلها. في بيثون ، هذا ليس هو الحال. على سبيل المثال ، يتم تثبيت حزمة في نفس البيئة ، وجميع الحزم التي تستخدمها تستخدم نفس الإصدار من هذه الحزمة. للقيام بذلك ، تحتاج إلى حل التبعيات بشكل صحيح - اختر إصدار هذه الحزمة التي ترضي عمومًا جميع الحزم في هذه البيئة. المهمة ليست تافهة: تعتمد الحزم على بعضها البعض ، كل شيء متشابك ، وحل التبعيات أمر صعب. لا يوجد عمليا محلل في بايثون. حل ذكي هو فقط في الشعر و DepHell.

كل هذا معقد إلى حد كبير بسبب حقيقة أن pypi.org لا يقدم في كثير من الأحيان معلومات حول تبعيات الحزمة ، لأنه يجب أن يحدد العميل هذه المعلومات ، لا يمكن لخادم PyPI اكتشافها بنفسه. لذلك ، عندما تقول PyPI أن الحزمة لا تحتوي على تبعيات ، لا يمكنك الوثوق بها. يجب عليك تنزيل الإصدار بأكمله وإلغاء ضغط وتحليل تبعيات الحزمة من setup.py. هذه عملية طويلة ، لذلك لا يمكن أن يكون محلل في Python سريعًا.

ليس فقط عدد قليل من محللات في بيثون ، بل هي أيضا بطيئة في التصميم.

في تقريري أريد أن أخبر كيف يعمل حل DepHell: كيفية إنشاء رسم بياني تبعية ، وكيف يبدو هذا الرسم البياني ، لماذا تكمن معظم المقالات العلمية في كيفية حل التبعيات والعمل مع هذا الرسم البياني. بالطبع ، هناك أوراق بيضاء حول كيفية عمل كل هذا. قام الأشخاص الأذكياء بكتابة مقالات باستخدام خوارزميات ، لكن في أغلب الأحيان لا يعملون لصالح بايثون. لذلك ، سوف أصف كيف أعمل مع دقة التبعية في الممارسة العملية في DepHell.

- كثيرا ما أسمع من المبرمجين أنهم يستخدمون نقطة ، وأن كل شيء يعمل بشكل جيد لهم. ماذا يفعلون خطأ؟

إنهم محظوظون ، فهم لا يواجهون صراع التبعيات. على الرغم من أن المشكلة يمكن أن تنشأ عندما تضع عبوتين فقط في بيئة نظيفة. تم مؤخرًا إصدار حزمة من التغطية 5.0 ، وإذا قمت فقط بتحديد pip install pytest-cov coveralls ، pip install pytest-cov coveralls النقطة إلى الترتيب وستحدد الحزمة الأولى أحدث إصدار من التغطية ، وهو 5.0. يعمل مبدأ المطابقة الأولى في نقطة ، لذلك حتى إذا كانت النسخة غير متوافقة مع الحزمة الثانية ، فسيتم تثبيتها بالفعل على الحزمة الأولى. في كثير من الأحيان هذا النهج يعمل ، ولكن ليس دائما.

بالإضافة إلى ذلك ، هناك سؤال مع البيئات القابلة للتكرار. نظرًا لأن pip تضع دائمًا أحدث إصدار ، فقد تختلف الإصدارات في البيئة المحلية والإنتاج. لحل هذه المشكلة ، من المعتاد إصلاح التبعيات. وعندما تكون التبعيات ثابتة بالفعل ، يجب الإشارة إلى الإصدارات المحددة التي يجب تثبيتها ، ثم تعمل النقطة بالفعل بشكل جيد. لا يحتوي Pip على محلل ، ولكنه يحدث عندما يحل شخص آخر التبعيات الخاصة به ، مثل DepHell أو Poetry.

- لماذا يكتسب هذا الموضوع هذه الأهمية الآن ، كما تعتقد؟ لماذا لم يحدث أي شيء من قبل ، ولكن الآن ذهب ، وحتى في اتجاهات مختلفة؟

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

من المستحيل عمومًا تحليل Setup.py ، ولا يمكن تنفيذه إلا. إذا أردنا ، على سبيل المثال ، كتابة خادم في Go لتوزيع الحزم بسرعة على Python ، فلن نتمكن فقط من التقاط وقراءة setup.py ، لأنه ملف قابل للتنفيذ. وفقًا لذلك ، من أجل تنفيذه ، تحتاج إلى Python وبيئة كاملة ، وغالبًا ما يكون المشروع بالكامل في مكان قريب ، ويتم تثبيت بعض التبعيات المحددة. إلى جانب كل هذه الصعوبات ، قد يكون تنفيذ setup.py خطيرًا ، لأنه سيتم تنفيذ بعض التعليمات البرمجية الأخرى على جهاز الكمبيوتر الخاص بك. في الواقع ، من المخيف حتى تنفيذ التعليمات البرمجية من أسفل المستخدم الحالي ، لأنه على سبيل المثال ، إذا تلقى مفتاح SSH الخاص وأرسله إلى مكان ما ، فسيكون ذلك مأساة كبيرة.

الخيار الثاني لتحديد التبعيات ، والذي كان موجودًا لفترة طويلة ويعمل الجميع معه ، هو requirements.txt. كما أنه من المستحيل تقريبًا تحليلها بنفس الطريقة. يمكن Pip ، ولكنه يفعل ذلك ، صعب للغاية: الوظائف التي تستدعي الوظائف ، التكرارات ، كل شيء مختلط. علاوة على ذلك ، يمكن لـ pip قراءة بعض مفاتيحه من requirements.txt ، على سبيل المثال ، يمكن تحديد فهرس للتنزيل. ولكن هذا لا يعمل مع جميع المفاتيح.

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

لا يهدف Pip نفسه لاستخدامه كمكتبة. هذه أداة CLI حصرية لا يمكن استخدامها إلا من وحدة التحكم. يتم إخفاء كل شفرة مصدر النقطة خلف _internal ، ويقول المطورون مباشرةً: "لا تستخدم هذا!". وكل إصدار يكسر التوافق مع الوراء. إنهم بصراحة لا يضمنون التوافق ويمكنهم تغيير أي شيء في أي وقت. وهذا ما يحدث - في كل مرة يأتي إصدار جديد مع نقطة ، أتعلم عنها من CI مكسورة في DepHell.

- ماذا عن في لغات أخرى؟ هل هو بنفس السوء هناك ، أم أن كل هذه المشاكل يتم حلها في مكان ما؟

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

وهكذا ، في بيثون ، يتم تنظيم العمل مع التبعيات تدريجيا من قبل المجتمع. حلول جديدة آخذة في الظهور. بمجرد أن تم بناء Distutils في Python ، أدرك الناس أن لديها الكثير من المشكلات ، Setuptools الإضافية. تم تطوير easy_Install لاحقًا لتثبيت الحزم ، لكنه واجه أيضًا مشكلات. لحلها ، وخلق نقطة. الآن النقطة لديها الكثير من المشاكل. مصادرها تتغير باستمرار ، لا توجد بنية ، لا توجد واجهة على الإطلاق.

المجتمع يحاول الخروج بشيء ما. على سبيل المثال ، كان هناك نقاش طويل حول المشكلة تسمى المتطلبات 2.0 حول كيفية جعل المتطلبات مفهومة للناس على حد سواء (هنا الإصدار ، وهنا علامات) ، وبرمجيًا من لغات أخرى.

لقد قاموا بإنشاء Pipfile ، ولكن نظرًا لأن النقطة pip مربكة للغاية ، لم يتمكنوا من إضافة دعم Pipfile إليها.

المطورين يريدون القيام بذلك ، بالطبع. على الأرجح ، في يوم من الأيام سيكونون قادرين ، لكن حتى الآن لا يمكن للنقاط أن تدعم Pipfile. لذلك ، جعلنا pipenv للعمل مع Pipfile والبيئة الافتراضية ، وبعض الأغلفة الأخرى مع البيئة. ولكن في pipenv ، أيضًا ، كل شيء مختلط ومربك.

بالنسبة للغات أخرى ، أحب الطريقة التي يتم بها تطبيق إدارة التبعية في Go. في السابق ، لم يكن هناك إصدار في الإصدار ، كان هناك go get ، حيث تشير من أي مستودع إلى الحزمة التي سيتم تنزيلها. من وجهة نظر المبتدئين ، يعد هذا أمرًا مريحًا: يمكنك ببساطة كتابة go get والحزمة موجودة بالفعل في النظام. وعندما تبدأ العمل مع Python ، تنهار كومة كاملة من كل شيء على الفور: بعض الإصدارات ، PyPI ، pip ، requirements.txt ، setup.py ، الآن Pipfile ، Poetry ، __pymodules__ ، إلخ.

مع تطور بايثون تدريجياً وبمساعدة المجتمع ، تتراكم الإرث في النظام البيئي. كان Go مجرد go get ، ولكن مرة أخرى نشأت المشكلة التي تحتاج إلى إصلاح التبعيات بحيث ، على وجه الخصوص ، كانت البيئة قابلة للتكرار.

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

لم يكن هناك شيء من هذا القبيل في Go ، وظهر التوريد: تم اتخاذ جميع التبعيات ووضعها في دليل واحد فقط. هذا حل متسخ ، يشبه node_modules ، والذي تم تطبيقه في Go لبعض الوقت باستخدام حلول node_modules الخارجية. في Python ، يتم استخدام هذا النهج أيضًا ، على سبيل المثال ، لدى pip دليل vendor . عندما تقوم بتثبيت نقطة ، لا يتم عمل التبعيات ، وقد تعتقد أن كل شيء رائع للغاية ولا توجد تبعيات على الإطلاق ، ولكن في الواقع كل هذه العناصر موجودة داخل vendor .

منذ حوالي عام ، ظهر go.mod (Go Modules) في Go. هذه أداة مضمنة جديدة ، ولكن go get مدعومة أيضًا. يحتوي المشروع على ملفين:

• واحد يصف التبعيات التي يعمل بها المشروع مباشرة ؛
• والآخر هو ملف القفل ، والذي يصف كل التبعيات وإصداراتها المحددة.

هذا هو الحل المركزي بارد.

ما هو مهم ، يصرون على أن بعض الأشياء يجب أن تبدو بطريقة معينة. على سبيل المثال ، في Go ، يجب أن يكون الإصدار هو الإصدار الدلالية.

لدى Python أيضًا مواصفات حول كيفية ظهور الإصدار. لهذا ، يوجد PEP 440. لكن ، أولاً ، المواصفات معقدة للغاية: لا يوجد فقط ثلاثة مكونات (أرقام) ، ولكن أيضًا إصدار تجريبي وفترة ما بعد الإصدار وعصر (عندما تتغير طريقة الإصدار). ثانياً ، لم يتم قبول PEP 440 على الفور ، لقد جاءوا إليها أيضًا بشكل تدريجي ، وبالتالي يتم دعم الإصدار القديم ، مما يعني أنه يمكن استخدام أي شيء كإصدار - أي سطر مثل "Hello world!".

- قلت إن المجتمع يطور اللغة بشكل تدريجي ، لذلك هناك عدد كبير من الحلول. ولكن لماذا لا تتخلص من كل هذه القمامة؟ لماذا لا تطرد Distutils ، تتخلى عن القديم وغير الضروري الذي لا يستخدمه أحد ، وبدلاً من ذلك تقدم ممارسات وأدوات جديدة بنشاط؟

للحفاظ على كل هذا أمر منطقي ، بحيث لا يزال بإمكانك تثبيت الحزم القديمة. من المستحيل الإصرار على أنه من الضروري القيام بذلك ، وليس غير ذلك ، لأن القرار يتخذ من قبل المجتمع. لا أحد من مطوري Core Python يأتون ويقولون: "هذا كل شيء ، نحن نفعل كل شيء الآن ، ولا مسامير."

Go لديه كل ما تحتاجه للعمل مع التبعيات على الفور. في Python ، تحتاج إلى إعادة تثبيت كل شيء من الخارج ، ولا تزال بحاجة إلى فهم ما هو بالضبط. في معظم الأحيان ، نقطة كافية ، ولكن الآن خيارات أخرى تظهر.

على الموقع مع توصيات الحزمة الرسمية من Python Packaging Authority ، المجموعة التي تصنع pip ، pipenv ، PyPI ، تتم كتابتها لاستخدام pipenv. مع pipenv هي قصة أخرى. أولا ، لديه قرار الفقراء. ثانياً ، لم تكن هناك إصدارات لفترة طويلة جدًا ، وينتظر المجتمع بالفعل أن يعترف المبدعون بصدق أن هذا المشروع قد مات. المشكلة الثالثة مع pipenv هي أنها مناسبة للمشاريع فقط ، ولكن ليس للحزم: يمكنك تحديد تبعيات المشروع في pipenv ، لكن لا يمكنك تحديد اسمها ، وإصدارها ، وبالتالي ، ضعها في حزمة للتنزيل على PyPI. اتضح أن اتباع توصيات هيئة بيثون للتعبئة واستخدام pipenv لا يزال غير كافٍ لإثبات ذلك.

الشعر يحاول أن يكون ثوريا. بشكل أساسي لا يُنشئ ملف setup.py ، والذي سيكون مفيدًا للتوافق مع الإصدارات السابقة ، لأن Poetry يريد أن يكون التنسيق الجديد والوحيد لكل شيء. إنه يعرف كيفية جمع الحزم ولديه ملف قفل ، وهو أمر ضروري للمشاريع. ومع ذلك ، فإن الشعر لديه الكثير من الأشياء الغريبة ، العديد من الميزات المألوفة غير مدعومة.

- ما رأيك هو مستقبل النظام البيئي من حيث العمل مع التبعيات؟ التنبؤ الخاص بك.

كل شيء يتحسن أكثر أو أقل. على سبيل المثال ، رأيت وظيفة شاغرة في النقطة ، ووعد المطور الذي يضعها بالترتيب بأموال كثيرة. ربما سوف تصبح نقطة الحل أكثر عالمية. لكنك بحاجة إلى أن يأخذها شخص ما على محمل الجد: تعال وقل إننا نفعل ذلك بهذه الطريقة ، والآن نتبع بعض PEP الأكثر صرامة ، وسوف نصر على الالتزام به (لأن PEP هي مجرد توصيات لا أحد في الواقع ليس مطلوبا لمتابعة).

على سبيل المثال ، كان لدينا مثل هذه القصة: تم تأمين إصدار معين من PyYAML في ملف القفل. في يوم من الأيام تمر اختبارات CI ، وننتشر للإنتاج ، وكل شيء يقع هناك ، لأنه لم يتم العثور على إصدار PyYAML. كان الشيء الذي تم حذف الإصدار المقفل من pypi.org. الجميع كان ساخطا ، تحديث ملف القفل ، نجا بطريقة أو بأخرى ، ولكن بقيت الرواسب.

منذ وقت ليس ببعيد ، ظهر PEP 592 ؛ لقد تم اعتماده بالفعل ويتم صيانته في نقطة ، والذي ظهرت فيه الإصدارات المنبوذة. يعني Yank أن الإصدار لم تتم إزالته بالكامل من pypi.org - إنه مخفي. هذا هو ، إذا حددت أنك تحتاج ، على سبيل المثال ، إصدار PyYAML أكبر من 3.0 ، فسوف يتخطى pip الإصدارات التي تم حذفها وتثبيت أحدث إصدار متاح. ولكن إذا تمت الإشارة إلى إصدار محدد في ملف القفل ، وكان هذا الإصدار خشنًا ، فستقوم النقطة بتثبيته على أي حال. وبالتالي ، فإن قفل الملفات ونشرها لن ينكسر ، ولكن ، إن أمكن ، لن يتم استخدام الإصدار القديم.

الشيء الثاني المثير للاهتمام هو PEP لـ __pymodules__ . هذه بيئات افتراضية خفيفة الوزن: تفتح دليل المشروع ، وتكتب pip install PyYAML ، ولا يتم تثبيت PyYAML على المستوى العالمي ، ولكن في دليل __pymodules__ . عندما يبدأ Python في هذا الدليل ، فإنه يستورد PyYAML ليس على المستوى العالمي ، ولكن من هذا الدليل.

أنا أسميها البيئات الافتراضية في الحد الأدنى ، لأن هناك أقل عزلة. على سبيل المثال ، لا يوجد وصول إلى الملفات الثنائية. عند تنشيط بيئة افتراضية مع تثبيت pytest ، يمكن استخدامها من وحدة التحكم: ما عليك سوى كتابة pytest والقيام بشيء ما. مع __pymodules__ ستكون متاحة للاستيراد ، ولكن ليس الثنائيات ، حيث لن يتم تثبيتها بالفعل.

تم تصميم PEP لتسهيل الأمر على المبتدئين. بحيث لا يحتاجون إلى التعامل مع جميع تعقيدات البيئات الافتراضية ، ولكن ببساطة تثبيت كل ما تحتاجه في __pymodules__ خلال pip pip.

- حسنا ، المستقبل في توقعاتك أكثر إشراقا من الآن.

نعم ، لكن كما قلت ، إذا لم يأت أحد وقال إننا نعيد الإرث ونحاول التخلص من الإرث ، فستظل المشاكل قائمة. نحن الآن نقوم بتجميع الأدوات وتجميعها ، وسيكون من المستحيل التخلص تمامًا من أي منها في المستقبل القريب.

- ما رأيك ، لماذا لا يستطيع أي من المطورين تحديث التبعيات في أي مكان تقريبًا - لا في الشركات ولا في المصادر المفتوحة - تم بناء عملية التعامل مع الإصدارات الأمنية ، من حيث المبدأ ، مع الإصدارات الثانوية أو الرئيسية الجديدة. أين ترى المشاكل هنا؟

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

تم تنفيذ تطبيق Go work with test ، حتى في برامج Go Modules التعليمية ، يتم كتابة كيفية تحديث التبعيات: يمكنك تحديث بعض التبعيات وتشغيل الاختبارات. علاوة على ذلك ، لا تعمل الاختبارات فقط ، ولكن أيضًا هذا الاعتماد.

لا يزال هناك جانب مثير للاهتمام يستحق الذكر: هل يجب أن تكون الاختبارات في حزم في بيثون؟ عند تنزيل حزمة من pypi.org ، هل يجب أن تكون هناك اختبارات؟ من الناحية النظرية ، ينبغي أن يكون لديهم ، وحتى آلية لتشغيلها: في setup.py ، يمكنك تحديد كيفية إجراء الاختبارات ، وما هي التبعيات التي لديهم.

ولكن ، أولاً ، لا يعرف الكثير من الأشخاص كيفية تشغيلها ولا يجرون اختبارات تعتمد عليها. لذلك ، غالباً ما تكون غير مطلوبة. ثانياً ، غالبًا ما يكون لهذه الاختبارات تركيبات صعبة للغاية ، وبالتالي فإن تضمين الاختبارات في حزمة يعني زيادة حجم العبوة 6-10 مرات.

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

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

- لماذا ، في رأيك ، في Python ، أدوات الإصدار الدلالي التلقائي ليست شائعة؟

أعتقد أن إحدى المشكلات هي أنه يمكن وصف الإصدار في العديد من الأماكن. غالبًا ما يوجد ثلاثة منها: تنسيق وصف بيانات تعريف المشروع (pypi.org ، poety ، setup.py ، إلخ) ، داخل المشروع نفسه وفي الوثائق. ترقية إصدار في ثلاثة أماكن ليست صعبة للغاية ، ولكن من السهل أن تنسى.

لدى DepHell فريق لترقية الإصدار.علاوة على ذلك ، تم تكوين DepHell للعمل مع جميع تنسيقات التبعية ؛ وبالتالي ، يمكنه العمل مع الإصدارات بأي تنسيق. يمكن أن يكون إصدار دلالي ، إصدار متوافق ، إلخ. و ثيقة وصفها، ما هي الطرق من الإصدارات، وانها مثيرة للاهتمام جدا.

ومن المثير للاهتمام ، تم حل هذه المشكلة في Flit. Flit هي أداة بسيطة مع تنسيقها الخاص لوصف بيانات تعريف الحزمة ، لتفكيك الحزمة وتنزيلها. هناك أربعة فرق فقط: init، build، publishوinstall . , , PyPI — . Flit , . docstring . , .

DepHell Flit . description, , , .

, .

DepHell import , , , , . , , .

, Moscow Python Conf++ 27 . DepHell backend, web, , AI/ML, , DevOps, , IoT, infosec . , , Moscow Python Conf++.