रैक

Question

के लिए अनावश्यक बंडलर निर्भरता घोषणाओं से बचें स्टार्टअप पर, एक रैक एप्लिकेशन की कल्पना करें, स्टार्टअप पर, उन अनुप्रयोगों के लिए कुछ अन्य रूबी अनुप्रयोगों और मानचित्र मार्गों के उदाहरण बनाता है। इस एप्लिकेशन में 1.2.2 की रैक निर्भरता है।

अब कल्पना करें कि हम एक उप-एप्लिकेशन विकसित कर रहे हैं जो इस एप्लिकेशन द्वारा चलाया जाएगा। इसमें 1.2.6 की सिनात्रा निर्भरता है और बंडलर का उपयोग करता है। , दुर्भाग्य से

source "http://rubygems.org" 

gem "sinatra", "1.2.6" 

जब हम bundle install इस उप आवेदन, Bundler, माता पिता के आवेदन की रैक 1.2.2 निर्भरता का कोई ज्ञान के साथ, यह है कि रैक का नवीनतम संस्करण स्थापित हो जाएगा: यह gemfile एक बंजर है सिनात्रा 1.2.6 के साथ संगत: वर्तमान में 1.3.2। हमारे Gemfile.lock हो जाएगा:

GEM 
    remote: http://rubygems.org/ 
    specs: 
    rack (1.3.2) 
    sinatra (1.2.6) 
     rack (~> 1.1) 
     tilt (< 2.0, >= 1.2.2) 
    tilt (1.3.2) 

PLATFORMS 
    ruby 

DEPENDENCIES 
    sinatra (= 1.2.6) 

जब हम माता-पिता आवेदन (जो हमारे उप आवेदन शुरू होता है) प्रारंभ करने का प्रयास है, हम मिल जाएगा:

You have already activated rack 1.2.2, but your Gemfile requires rack 1.3.2. Consider using bundle exec. (Gem::LoadError)

सही तरीका क्या है इस स्थिति को संभालने के लिए? हां, हम स्पष्ट रूप से रैक 1.2.2 की आवश्यकता हो सकती है, लेकिन हम प्रभावी रूप से निर्भरता की निर्भरता बताते रहेंगे। मैं कल्पना करता हूं कि, आदर्श रूप से, मूल आवेदन एक मणि होगा जो हमारे उप-आवेदन की आवश्यकता होगी, लेकिन इस स्थिति में, हमारे पास ऐसा करने की क्षमता नहीं है।

Answer 1

कोशिश मणि स्थानीय

Answer 2

आपका "मुख्य" प्रक्रिया subprocesses लांच करने के लिए bundle exec का उपयोग करना चाहिए से रैक 1.2.2 नष्ट करने के लिए, त्रुटि संदेश की सिफारिश की बस के रूप में।

कि भीतर यह खुदGemfile के बंडल संदर्भ, नहीं वैश्विक मणि संदर्भ है शुरू करने के लिए नए एप्लिकेशन के लिए बाध्य करेगा। नतीजतन, नया ऐप रैक 1.3.2 या बाद में, रैक 1.2.2 का उपयोग करके लॉन्च किया जाएगा।