تبعيات كود المنبع

استراتيجيات جمع البيانات (اختياري)

• يوفر Libraries.io ماسحًا ضوئيًا يركز على التبعية لمدير الحزم (متاح أيضًا من خلال Tidelift).

• يمكن تنفيذ مقياس تبعية الكود الأولي عن طريق تحليل ملف تبعية المشروع أو باستخدام الأدوات الحالية التي تفحص بيانات مدير الحزم للغات المستخدمة (على سبيل المثال ، package.json لـ JavaScript npm ، pyproject.toml / requirements.txt لـ Python و Gemfile / Gemfile .lock لروبي ، وما إلى ذلك). ملاحظة: يستخدم C / C ++ بشكل عام مديري حزم النظام. تصبح الأمور أكثر تعقيدًا مع لغات متعددة ، بقدر ما يلزم فحص العديد من ملفات التبعية الخاصة بلغة معينة.

• المعلمات يجب أن تتضمن جميع التبعيات التي تم تعدادها الإصدار (الإصدارات) المحددة المستخدمة لكل تبعية. لاحظ أن بعض الأنظمة لا تدعم أو لا تستخدم "تثبيت الإصدار" وبالتالي لا تفرض إصدارًا معينًا.

• عمق شجرة التبعية

  • التبعية المباشرة - التبعيات من الدرجة الأولى ، كما هو معلن في كود المصدر و / أو تكوين مدير الحزم (على سبيل المثال ، requirements.txt ، Gemfile ، إلخ.)
  • التبعية العابرة - التبعيات غير المباشرة ، أي التبعيات التي تتجاوز تبعيات الدرجة الأولى والتي يشار إليها أيضًا باسم التبعيات المتداخلة أو التبعيات من الدرجة الثانية. على سبيل المثال ، يعتمد المشروع "أ" قيد التقييم على المشروع "ب" ويعتمد المشروع "ب" على المشروع "ج". بالنسبة للمشروع "أ" ، يعتبر المشروع "ج" تبعية انتقالية.
  • التبعية الدائرية - التبعيات التي إذا تم تتبعها تؤدي في النهاية إلى نفسها. في الأنظمة التي تسمح بالتبعية الدائرية ، نفترض أنه يتم حساب تبعية معينة مرة واحدة فقط في هذه الحالة.

• دولة التبعية

  • التبعية الثابتة - التبعية موجودة في جميع الحالات.
  • التبعية الديناميكية - تغييرات التبعية في الاستخدام وفي سياقات أخرى

• الاعتماد على الخدمة الخارجية مثل استخدام API

• تبعية التنفيذ - التبعيات المطلوبة لتنفيذ البرنامج. لاحظ أنه يتم عادةً استبعاد أنواع معينة من التبعيات من الأعداد ، كما هو موضح أدناه. قد تكون هذه واحدة أو أكثر مما يلي:

  • بناء التبعية - يتطلب الكود إنشاء جزء من البرنامج
  • تبعية الاختبار - تتطلب الكود اختبار جزء من البرنامج
  • تبعية وقت التشغيل - تتطلب التعليمات البرمجية تشغيل جزء من البرنامج

• تفاصيل تبعية وقت تشغيل اللغة (على سبيل المثال ، بيئة وقت تشغيل بايثون)؟ (الافتراضي لا). يتم توفير هذه التفاصيل نظرًا لأهمية تبعيات وقت التشغيل لضمان الجودة في أنظمة السلامة الحيوية.

  • غالبًا ما يتم التحكم في وقت تشغيل اللغة الذي سيتم استخدامه بواسطة البيئات الافتراضية ، على سبيل المثال ، venv في بايثون ؛ في Ruby كنت تستخدمه كثيرًا rbenv or RVM لتنفيذه (وعادة ما يتم تضمينه في "Gemfile" أو "Gemfile.lock" و .ruby-version)
  • تعمل PyPi بشكل مطرد على زيادة منطق "رفضها تجميع المكتبات / التبعيات غير المتوافقة". لقد بدأت في "كسر البنى".
  • لسوء الحظ ، ليست كل أنظمة التغليف لديها اتفاقية لتسجيل معلومات الإصدار لجميع التبعيات متعدية ، حتى داخل نظامها البيئي (يجب أن يكون ذلك على المدى الطويل)
  • في بعض الأنظمة ، هناك العديد من أوقات التشغيل المحتملة التي قد يصعب تمييزها. (على سبيل المثال ، هناك العديد من تطبيقات Common Lisp وغالبًا ما يعمل أي منها.)

• مكتبات اللغة المضمنة في الكونت (على سبيل المثال ، "re" في Python)؟ (الافتراضي لا)

  • عادةً ما تكون العديد من المكتبات المضمنة تبعيات قابلة للتنفيذ. ومع ذلك ، يتم تثبيتها عادةً "بشكل جماعي" عن طريق اختيار تطبيق اللغة ، وغالبًا ما يتم استبعادها من التهم لتبسيط التحليل.
  • مثال: بشكل افتراضي ، pip freeze لا تتضمن هذه الأنواع من المكتبات / التبعيات "المضمنة في اللغة".
• يتم حساب إصدارات متعددة من نفس التبعية بشكل مستقل. تدعم بعض الأنظمة إصدارات متعددة من نفس التبعية داخل النظام ؛ في مثل هذه الحالات ، يتم عدهم بشكل منفصل.

ملحوظة: غالبًا ما يكون من المهم توفير معلومات حول إصدار الإصدار الرئيسي والثانوي لتطبيق اللغة في وقت التشغيل.

• بعض التهم والتحليل يحتاج إلى هذه المعلومات. غالبًا ما يتم حذف أوقات تشغيل اللغة والمكتبات المدمجة (انظر أعلاه) ، وتعمل هذه المعلومات كاختصار لتوفير هذه المعلومات الإضافية.
• مثال: يدعم نظام Ruby البيئي مواصفات إصدار وقت تشغيل اللغة في Gemfiles وملف إصدار .ruby.
• مثال: غالبًا ما تنظم إصدارات Python من PyPi و Anaconda إصدارات مختلفة من المكتبات بطرق مختلفة.

فلاتر

• الاتجاهات بمرور الوقت (على سبيل المثال ، هل أعتمد على مشاريع أكثر أو أقل من العام الماضي)
• عدد الإصدارات لكل تبعية
• عدد المراجع لنفس التبعية

المرئيات