Composer: ضع في اعتبارك إضافة دعم وراثي أساسي لـ composer.json

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

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

النسخ في الاختبارات / لا تحتاج حقًا إلى أن تكون نسخًا كاملة ، فهي تحتاج فقط إلى الطلب (والتحميل التلقائي على ما أعتقد) نظرًا لأن الأمر يتعلق فقط بتحميل تبعيات مختلفة ، فهي لا تحتاج إلى معلومات الحزمة الكاملة مع الإصدار والاسم وما إلى ذلك.

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

هل يمكن أن تشرح كيف يكون هذا مفيدًا لتقسيم الشجرة الفرعية؟

يمكن أن يكون لديك المعلومات الشائعة في ملف ترث منه في جميع تقسيمات الشجرة الفرعية.

كيف يمكنك أن ترث منه إذا لم يكن موجودًا في انشقاقات الشجرة الفرعية؟

ولكن كيف تحصل على هذه المعلومات الشائعة عندما يكون لديك فقط شجرة فرعية فردية؟

أعتقد أن استخدام git filter-branch لن يكون هذا ضروريًا ، أي أنه سيكون لديك الملف الأساسي في جميع عمليات التقسيم ، لكنني لم أجربه.

أنا في موقف مشابه أحاول اختبار العقيدة / phpcr-odm مقابل الخلفيات المختلفة. ما أريده حقًا هو القدرة على القيام به:

php composer.phar install jackalope/jackalope-jackrabbit
php composer.phar install

لست متأكدًا مما إذا كانت هذه هي نفس حالة الاستخدام بالضبط (أو إذا كانت الحاجة التي أحتاجها قد تم حلها بالفعل بطريقة عشوائية):
باستخدام EZP ، كلا الإصدارين 4 و 5 ، نوزع composer.json الموجود في جذر "مشروع المستخدم" (أو تطبيق الويب). هذا ليس مثاليًا لأنه من المحتمل أن يكون لدى المستخدم النهائي الملحن json الخاص به - إذا اخترق للتو الملحن الذي نقدمه ، فستفقد تغييراته في الترقيات.
أنظف حل يمكنني التفكير فيه هو الحصول على composer.json واحد بما في ذلك آخر ، نوع من composer-user.json.
هل هذا منطقي؟
ملحوظات:

• إن تسليم الملحن الرئيسي json كجزء من CMS يجعل من السهل عليه استخدام كل الأشياء الجيدة التي تأتي مع كونه حزمة الجذر
• لا يمكننا الاعتماد فقط في cms composer.json على حزمة "user-project" بطريقة قياسية ، حيث لا يوجد اسم ثابت لها

لدي حالة استخدام مماثلة مثل gggeek ، حيث قد يرغب المستخدم في إضافة متطلبات مخصصة إلى ملف المؤلف والتي لا ينبغي تجاوزها عند الترقية.

gggeek +1 هنا. لدي العديد من التطبيقات المرتبطة وتستخدم الملفات المشتركة. يمتلك كل تطبيق حاليًا composer.json لكنهما متطابقان في الغالب مع اختلافات طفيفة. أرغب في الحصول على composer.json في المساحة المشتركة وواحد لكل تطبيق حتى يتمكن الملحن من القراءة من كليهما في كل مشروع.

+1

+1

+1

+1

+1 كذلك هنا ، وبصفتيgggeek ، هذا بالضبط موجود في إعداد eZ Publish (EZP) 5 الذي أواجه هذه المشكلة حاليًا.

+1

+1

أود أن أتفق مع gggeek هنا ، ولكن من المحتمل ألا تكون نفس حالة الاستخدام مثل هذه المشكلة.
ومن الناحية المثالية ، يجب أن تكون حالة استخدام gggeek عبارة عن ملف dist في الريبو المنبع ، وملف المستخدم الاختياري الذي يحتوي على _always_ يوسع التوزيع.

+1

+1

: +1:

+1 سأستخدم هذا كثيرًا أثناء التطوير

لقد قمنا بتطوير برنامج Composer-merge-plugin لميدياويكي لإضافة هذه الميزة.

يحتوي مستودع ميدياويكي الأساسي على ملف composer.json يتضمن ملف composer.local.json إن وجد. نظرًا لأن بعض امتدادات ميدياويكي تحتوي أيضًا على تبعيات مثبتة عبر الملحن ، فإن مسؤول النظام سيصدر هذه الملفات composer.json في ملف composer.local.json الخاص به ، وتشغيل "تحديث الملحن" سيجلب كل شيء.

+1

سيكون إرث المشروع (على غرار ما يفعله مافن) رائعًا.

+1

+1

+1

+1 مواجهة حالة استخدام مماثلة لـgggeek

+1

+1

هذا مفيد للغاية لحالة الاستخدام التي وصفها gggeek . على عكس اقتراح schmitt joh ، في حالة الاستخدام هذه ، يجب تفضيل حقل include(s) ( انظر هنا ). تبدو بنية المعلمات الخاصة بالمكوِّن الإضافي composer-merge-plugin جيدة جدًا. يبدو أن هذا المشروع هو نقطة انطلاق جيدة.

مشروع آخر ، على ما أعتقد ، يرغب في استخدام هذه الميزة هو Roundcube Webmail . يستخدمون Composer لنظام البرنامج المساعد الخاص بهم. وأنا أفضل هذا الحل لمشروعي الشبيه بإطار العمل أيضًا.

الاستخدام الأساسي:

{
    /* ... main dependencies ... */

    "includes": [
        "composer-local.json"
    ]
}

أو شيء من هذا القبيل:

{
    /* ... main dependencies ... */

    "includes": {
        "local": "composer-local.json", /* local = no warning, if file not found */
        "test": "composer-test.json" /* to use: invoke `composer --test-mode` ? */
    }
}

+1

+1

قد يكون هذا أكثر فائدة من ميزة الدلائل المحلية. يمكنك تضمين مشاريع فرعية مشابهة للطريقة التي يمكنك بها في gradle.

+1

+1 هذا يحل مشكلة خاصة جدًا نواجهها في شركتي الآن باستخدام الملحن مع مشاريع متعددة.

+1 هذا سيجعل الأمر أكثر بساطة بالنسبة لعمليات تثبيت التطبيقات للحصول على إضافات مخصصة ، على سبيل المثال لتثبيت المكونات الإضافية. في Symfony ، سيجعل هذا إضافة عدة حزم تابعة لجهات خارجية أسهل.

+1 هذا سيجعل من الأسهل كثيرًا الحفاظ على صورة Wordpress ل docker الأساسية ثم إضافة المكونات الإضافية الخاصة بالتطبيق في حاوية / صورة تابعة

سيكون هذا إضافة رائعة لـ drupal عند استخدام ملفات التعريف والميزات

+ 1secondtruth أود استخدام هذه الميزة مع تطوير الحزم

mikebronner لقد تعاملنا مع مشكلات مماثلة في عملنا ،

يجب أن يعمل المكون الإضافي mikebronner composer-merge-plugin جيدًا في حالة استخدام مشروع رئيسي يريد تجميع ملفات composer.json من عدد من الحزم الفرعية المضمنة عبر وحدات git الفرعية أو حتى مضمنة في git repo أكبر.

قد يؤدي شيء بهذه البساطة إلى القيام بكل العمل المطلوب:

"require" : {
  "wikimedia/composer-merge-plugin": "dev-master"
},
"extra": {
  "merge-plugin": {
    "include": [ "*/composer.json" ]
  }
}

سيبحث هذا عن ملف composer.json في كل دليل فرعي من المستوى الأعلى للمشروع ويتضمن محتويات جميع الملفات الموجودة (على سبيل المثال ، foo/composer.json ، bar/composer.json ) في تكوين Composer الداخلي في وقت التشغيل.

كان المكون الإضافي composer-merge-plugin في الأصل معنيًا فقط بمعالجة التكوين تتطلب وتطلب مطوري البرامج ولكن تم توسيعه لدعم العديد من أقسام التكوين الأخرى .

إذا تمكنا من إبقاء هذا النوع من دعم حالة الاستخدام المعقدة بعيدًا عن Composer المناسب ولكن جعله متاحًا بسهولة لحالات الاستخدام المتقدمة من خلال آلية المكون الإضافي التي تبدو وكأنها ربح صاف لـ Composer نفسه من حيث كل من تعقيد الكود وقابليته للتوسع. ومع ذلك ، سأكون أكثر من سعيد لرؤية تطبيق أساسي مقترح ومدمج جعل المكون الإضافي composer-merge-plugin عفا عليه الزمن.

Seldaek إذا كان من الممكن تضمين هذا في واجهة برمجة تطبيقات البرنامج المساعد أيضًا ، فسيكون ذلك رائعًا.

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

نظرًا لأن الأشياء تتحرك أكثر فأكثر نحو الحزم والفصل ، أعتقد أنها ستكون ميزة مهمة أكثر فأكثر.

ريان

يرجى التوقف عن نشر +1 في كل مكان واستخدام الإبهام على منشور العلاقات العامة الرئيسي: https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

إذا كنت تستخدم ملفات composer.json متعددة مع بائع مختلف ، ينتهي بك الأمر بدليلين للبائعين.
lib.json مع vendor-dir / lib
composer.json مع vendor-dir / vendor

ثم اجعل lib واحدًا يتضمن "الملفات": ["vendor / autoload.php"]
وأن تتضمن شفرتك "lib / autoload.php".

قم بإنشاء دليل / lib مثل:
env COMPOSER = تثبيت ملحن lib.json

يتيح ذلك إدارة التعليمات البرمجية الخاصة بك بواسطة lib.json
ويحصل المستخدم على composer.json الخاص به مع تبعيات تتطلب وتطلب مطوري البرامج.

ك.

أنا فقط لا أرى أننا نعمل على هذا في أي وقت قريبًا أو في أي وقت ، لذلك سأغلق على أنه لن يتم إصلاحه ، على أساس أن المكون الإضافي composer-merge-plugin يعد حلاً جيدًا لأولئك الذين يحتاجون تمامًا إلى هذا .