إصدار مسحوب من PyPI ليس حكماً بسحب الحزمة

الخلاصة

• تصف PyPI yank كبديل غير هدّام للحذف.
• السمة data-yanked في PEP 592 قابلة للإزالة والإعادة، ولا تسجل قرار برنامج تثبيت بعينه.
• عرض الفهرس والقيد والاختيار والملف والتشغيل أدلة مستقلة.

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

إجراء إدارة PyPI الحالي يتم على release كامل، بينما تضع PEP 592 data-yanked على روابط Simple API، فيراه العميل عند الملفات. لا ينتج عن ذلك إيصال حذف أو دليل على صلاحية الناشر أو سجل تنزيل في جهاز محدد. حقلا JSON، yanked وyanked_reason، يصفان ملاحظة من الفهرس فحسب.

الاختيار الفعلي طبقة أخرى. تطلب PEP 592 تجاهل البديل المسحوب عندما يفي بديل غير مسحوب بالقيد، وتسمح برفضه حتى حين لا يبقى حل. القيد الدقيق وملف lock وسياسة الأداة ووقت الرصد والفهرس المرئي تغيّر النتيجة. لذلك لا يعيد الوسم الحالي بناء ما اختاره محلل سابق.

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

يقترح Daniel Kade خمسة سجلات مترابطة: ملاحظة مؤرخة للمشروع والإصدار؛ القيد أو lock؛ نسخة محلل الاعتماد وقراره وتحذيره وhash؛ دليل منفصل للحذف أو الصلاحية أو الثغرة؛ وجرد تشغيل منفصل. لا يجوز افتراض الوصلة بين هذه السجلات.

المصادر

1. PyPI Docs — Yanking
2. PEP 592
3. PyPI Docs — Storage Limits
4. PyPI Docs — JSON API