वैकल्पिक निर्भरता की जरूरत नहीं है

यह पोस्ट PHP पैकेज और शराब के व्यसनों के बारे में होगी। बल्कि, तथाकथित वैकल्पिक या प्रस्तावित निर्भरता (वैकल्पिक निर्भरता, सुझाव / देव-निर्भरता) के बारे में, जो कंपोजर.जॉन में परिभाषित हैं।

नशा क्या है?

शुरू करने के लिए, हम निर्भरता के साथ क्या करेंगे और यह सब क्या है। निम्नलिखित कोड है:

namespace Gaufrette\Adapter; use Gaufrette\Adapter; use \MongoGridFS; class GridFS implements Adapter { private $gridFS; public function __construct(MongoGridFS $gridFS) { $this->gridFS = $gridFS; } public function read($key) { $file = $this->find($key); return ($file) ? $file->getBytes() : false; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GridFS वर्ग Gaufrette सार फ़ाइल सिस्टम लाइब्रेरी का हिस्सा है, जिसे मैंने कुछ हद तक संशोधित किया है। इस कोड के सभी निर्भरता को निर्धारित करने के लिए, हमें अपने आप से निम्नलिखित प्रश्न पूछना चाहिए:

• इस कोड को काम करने की क्या आवश्यकता है?

लेकिन एक और बात सोचने के लिए:

1. त्रुटियों को न पाने के लिए आपको PHP के किस संस्करण को चलाने की आवश्यकता होगी?
2. शायद आपको कुछ विशिष्ट संस्करण डालने की आवश्यकता है?
3. क्या PHP एक्सटेंशन की जरूरत है?
4. आपको कौन सी PEAR लाइब्रेरी स्थापित करने की आवश्यकता है?
5. क्या पैकेज गायब हैं?

GridFS वर्ग में लौटकर, PHP संस्करण कम से कम 5.3 होना चाहिए, क्योंकि नामस्थान का उपयोग किया जाता है। इसके अलावा, \MongoGridFS



वर्ग की \MongoGridFS



, जो PHP के लिए एक विस्तृत एक्सटेंशन है और केवल इस एक्सटेंशन के संस्करण 0.9.0 से उपलब्ध है। लगता है कि सब कुछ संगीतकार.जॉन:

 { ..., "require": { "php": ">=5.3", "ext-mongo": ">=0.9.0" } .. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह सूची पर्याप्त है और अब ऐसा लगता है कि हमारे अनुप्रयोगों में इस वर्ग का उपयोग करने से कुछ भी नहीं रोक रहा है ... काश, ऐसा नहीं होता।

वैध knplabs / Gaufrette निर्भरता सूची

जैसा कि मैंने पहले कहा, GridFS Gaufrette लाइब्रेरी का हिस्सा है, जो इस्तेमाल की गई फ़ाइल सिस्टम के विवरण के बारे में चिंता किए बिना विभिन्न प्रकार के फ़ाइल सिस्टम पर फ़ाइलों को संग्रहीत करने के लिए एक सार फ़ाइल सिस्टम परत प्रदान करता है। इस लाइब्रेरी के संगीतकार.जॉन पर एक नज़र डालें:

 { "name": "knplabs/gaufrette", "require": { "php": ">=5.3.2" }, "require-dev": { ... }, "suggest": { ... "amazonwebservices/aws-sdk-for-php": "to use the legacy Amazon S3 adapters", "phpseclib/phpseclib": "to use the SFTP", "doctrine/dbal": "to use the Doctrine DBAL adapter", "microsoft/windowsazure": "to use Microsoft Azure Blob Storage adapter", "ext-zip": "to use the Zip adapter", "ext-apc": "to use the APC adapter", "ext-curl": "*", "ext-mbstring": "*", "ext-mongo": "*", "ext-fileinfo": "*" }, ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और यहाँ वह है, पहला आश्चर्य! लगभग सब कुछ जो पहले निर्भरताओं के बारे में पता चला था, बेकार है, क्योंकि पुस्तकालय का कहना है कि इसे बस PHP संस्करण की आवश्यकता नहीं है 5.3.2 से कम, और बाकी सब कुछ - स्वाद के लिए, वैकल्पिक या केवल देव प्रयोजनों के लिए - इसे कॉल करें जो आप चाहते हैं ।



बेशक, जो लोग लंबे समय से संगीतकार या पैकैगिस्ट का उपयोग कर रहे हैं, वे पहले से ही ऐसी चीजों के लिए उपयोग किए जाते हैं। लेकिन यह सिर्फ गलत दृष्टिकोण है। जैसा कि हमने पहले पाया, एक्स-मोंगो ग्रिड्स क्लास की एक सच्ची निर्भरता है, हालांकि संगीतकार.जसन हमें इसके विपरीत बताते हैं।



यह सब केवल इसका मतलब है कि अगर हम अपनी परियोजना में इस वर्ग का उपयोग करना चाहते हैं, तो यह केवल पैकेज knplabs/gaufrette



का उपयोग करने के लिए पर्याप्त नहीं है। मैंने अपने प्रोजेक्ट में एक्सट्रा-मोंगो को भी जरूरी बना दिया, जो एक गलती है: यह मेरा प्रोजेक्ट नहीं है जिसमें मोंगो एक्सटेंशन की जरूरत है, बल्कि knplabs/gaufrette



। इसके अलावा, मुझे कैसे पता चलेगा कि पूर्व-मोंगो का कौन सा संस्करण मुझे चुनना चाहिए? सुझाव ब्लॉक में जिन आश्रितों को इंगित किया गया है, वे इस बारे में बात नहीं करते हैं, मुझे इसे चुनने के लिए मजबूर करते हैं।

यह सिर्फ एक अलग पैकेज है।

knplabs/gaufrette



केवल एक ही व्यक्ति नहीं है जो इस तरह से कार्य करता है, जैसा कि वास्तविक निर्भरता प्रस्तुत करता है। पैकेज मालिकों के लिए विभिन्न वर्गों को जोड़ना सुविधाजनक है, जिनकी उपयोगकर्ताओं को आवश्यकता हो सकती है। या जरूरत नहीं है। इसलिए, यदि इन वर्गों का उपयोग वैकल्पिक है, तो उनकी निर्भरताएं भी वैकल्पिक हैं। हालांकि, पैकेज के मालिक यह भूल जाते हैं कि निर्भरताएं कभी वैकल्पिक नहीं होती हैं। उन्हें हमेशा आवश्यकता होती है, क्योंकि कोड केवल उनके बिना काम नहीं करेगा।

निर्णय

पैकेज डेवलपर्स को इस मामले में क्या करना चाहिए? उन्हें अलग करें। knplabs/gaufrette



के मामले में knplabs/gaufrette



इसका मतलब है कि फ़ाइल सिस्टम से सार करने के लिए आवश्यक सभी सामान्य कोड वाले knplabs/gaufrette



पैकेज होना चाहिए। और फिर प्रत्येक व्यक्तिगत एडाप्टर, जैसे कि ग्रिड्सएफएस, को अपने स्वयं के पैकेज में रहना चाहिए, उदाहरण के लिए, knplabs/gaufrette-mongo-gridfs



। और उसके पास पहले से ही उसकी निर्भरता होगी:

 { ..., "require": { "php": ">=5.3", "knplabs/gaufrette": "~0.1" "ext-mongo": ">=0.9.0" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और वह सब है, कहीं भी कोई छिपी हुई निर्भरता नहीं है, वे सभी आवश्यक हैं।



knplabs/gaufrette



बदले में, अब सभी पर कोई निर्भरता नहीं है, और एडेप्टर के साथ पैकेज सिर्फ ऐसे हैं:

 { "require": { "php": ">=5.3.2" }, "suggested": { "knplabs/gaufrette-mongo-gridfs": "For storing files using Mongo GridFS", ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस दृष्टिकोण के कई फायदे हैं:

• मुख्य पैकेज अधिक स्थिर होता जा रहा है। कुछ भी बदलने का कोई कारण नहीं है, क्योंकि सभी परिवर्तनशील हिस्से एडेप्टर के अंदर हैं।
• अलग-अलग पैकेज में अलग-अलग डेवलपर्स हो सकते हैं। उदाहरण के लिए, knplabs/gaufrette-mongo-gridfs
  
  
  
  को किसी ऐसे व्यक्ति द्वारा संशोधित किया जा सकता है जो MongoDB को अच्छी तरह से जानता है।
• उपयोगकर्ताओं को लाइब्रेरी के उन हिस्सों के अपडेट की निगरानी करने की आवश्यकता नहीं है जिनका वे उपयोग नहीं करते हैं।
• उपयोगकर्ताओं को अपनी परियोजनाओं के लिए अतिरिक्त निर्भरता को मैन्युअल रूप से नहीं जोड़ना होगा।

अगली बार, अपने पैकेज में प्रस्तावित निर्भरता को जोड़ने के बारे में सोचें कि क्या यह निर्भरता इस पैकेज में मान्य है? फिर पैकेज को अलग करें और आवश्यकतानुसार इस निर्भरता को निर्दिष्ट करें। यदि मुख्य पैकेज के सभी कोड इस प्रस्तावित निर्भरता के बिना काम करते हैं, तो इस मामले में इसे प्रस्तावित के रूप में इंगित किया जा सकता है।