बुंडलर के साथ संस्करणों का प्रबंधन करना

रेक अपडेट को हाल ही में संस्करण 0.8.7 से संस्करण 0.9.0 तक जारी किया गया था, जिससे समुदाय में बहुत शोर हुआ और एक बार फिर संस्करण नियंत्रण समस्या का पता चला। मैं स्थिति को स्पष्ट करना चाहता हूं और मुख्य बिंदुओं को दोहराता हूं जो मैंने पहले ही बुंडलर 1.0 की रिहाई के दौरान उल्लेख किया था। सबसे पहले, मैं काम के सरल नियमों के बारे में बात करूंगा, और फिर विवरणों में थोड़ा गहरा जाऊंगा।

सरल संस्करण

1. बंडल करने के बाद रिपॉजिटरी में Gemfile.lock जोड़ें।
2. Gemfile को बदलने के बाद, हमेशा bundle install पहली चीज़ bundle install करें - यह Gemfile.lock को "रूढ़िवादी" अपडेट करेगा। केवल रत्न जो आपने रत्न में बदल दिए हैं, बदल जाएंगे। बाकी सब कुछ वैसा ही रहेगा जैसा वह था।
3. यदि एक "रूढ़िवादी" अद्यतन संभव नहीं है, तो bundle update [somegem] आपको bundle update [somegem] करने की पेशकश करेगा। यह कमांड केवल निर्दिष्ट मणि और इसके लिए आवश्यक सभी निर्भरता को अद्यतन करेगा। शेष रत्न अक्षुण्ण रहेंगे।
4. यदि आपको खरोंच से सभी निर्भरता को फिर से हल करने की आवश्यकता है, तो आपको एक bundle update करने की आवश्यकता है।
5. जब आप निष्पादक चलाते हैं, ALWAYS bundle exec [command] माध्यम से ऐसा करते हैं। प्रलेखन से उद्धरण: कुछ मामलों में, bundle exec बिना फ़ाइलों को लॉन्च करना काम कर सकता है यदि यह फ़ाइल आपके सिस्टम पर स्थापित रत्न का हिस्सा है और किसी भी निर्भरता को लोड नहीं करता है जो आपके बंडल के साथ संघर्ष कर सकता है। हालांकि, यह विधि बेहद अविश्वसनीय है और कई समस्याओं का स्रोत है। यहां तक ​​कि अगर सब कुछ काम करने लगता है, तो यह एक तथ्य नहीं है कि यह कल या किसी अन्य सर्वर पर काम करेगा। अगला खंड, "निष्पादन योग्य", इस बारे में है।
6. याद रखें कि आप हमेशा अपने पुराने Gemfile.lock को git checkout Gemfile.lock या अन्य git checkout Gemfile.lock समान वापस कर सकते हैं।

निष्पादन योग्य फ़ाइलों

जब आप मणि को स्थापित करते हैं, तो रूबीगैम रत्न के साथ आने वाले सभी निष्पादन के लिए आवरण बनाता है। जब आवरण शुरू होता है, तो रूबीगैम शुरू होता है, जो मानक सक्रियण तंत्र का उपयोग करके खुद को मणि जोड़ता है। Rubygems सिस्टम पर स्थापित मणि के नवीनतम संस्करण को लॉन्च करेगा, भले ही Gemfile.lock में एक अलग संस्करण निर्दिष्ट किया गया हो। इसके अलावा, सभी रत्न निर्भरता के नवीनतम (संगत) संस्करण सक्रिय हो जाएंगे, भले ही अन्य संस्करण Gemfile.lock में निर्दिष्ट किए गए हों।

इसका मतलब यह है कि निष्पादन योग्य फ़ाइलों को साधारण कमांड के रूप में चलाने से केवल बुंडलर और उसकी सभी निर्भरताएं समाप्त हो जाती हैं। कभी-कभी यह एक समस्या नहीं है, क्योंकि डेवलपर्स के पास सबसे अधिक संभावना सभी रत्नों के सही संस्करण हैं। एक लंबे समय के लिए, रेक "सही" संस्करण के साथ इस तरह के एक मणि का एक उत्कृष्ट उदाहरण था, क्योंकि अधिकांश Gemfile.lock को 0.8.7 संस्करण में बंद कर दिया गया था, जो कि अंतिम उपलब्ध संस्करण था और सभी के लिए स्थापित किया गया था।

नतीजतन, एक गलत धारणा थी कि निष्पादन योग्य फ़ाइलों का प्रत्यक्ष लॉन्च बुंडलर के साथ संगत है और यह निर्भरता को हल करने के लिए उपयोग करता है। समस्याओं के मामले में, आमतौर पर आरवीएम से रत्नों का उपयोग करने की सिफारिश की गई थी, क्योंकि जेमफाइल.लॉक से संकलित एक अनिवार्य रूप से इसका मतलब था कि पर्यावरण की सभी निष्पादन योग्य फाइलें आवश्यक निर्भरता संस्करणों के साथ काम करती थीं।

दुर्भाग्य से, इस बैसाखी के कारण, लोग हमेशा bundle exec उपयोग करने के लिए प्रलेखन से सलाह को अनदेखा करते रहते हैं।

यह मानने का कोई कारण नहीं है कि कंसोल में rake foo टाइप करके, आप बुंडलर सैंडबॉक्स कोड चलाते हैं, क्योंकि वास्तव में यह किसी भी तरह से शामिल नहीं है और यह कहीं भी शुरू नहीं होता है। बुंडलर को डाउनलोड के आरंभ में सक्रिय किया जाना चाहिए और इसे बूटलोडर को बदलने में सक्षम होना चाहिए ताकि रत्नफ्लॉक में दिए गए रत्नों के आवश्यक संस्करण फिसल सकें। सीधे निष्पादक लॉन्च करके, आप बुंडलर को निर्भरता कनेक्शन प्रक्रिया में हस्तक्षेप करने से पहले रूबी कोड निष्पादित करते हैं। नतीजतन, आप जिस कोड की गिनती कर रहे हैं, वह बिल्कुल जुड़ा नहीं है। एक बार ऐसा हुआ, सब कुछ बहुत अप्रत्याशित हो जाता है।

bundle install --binstubs

bundle exec साथ इन सभी नृत्यों को किसी भी तरह से सुविधाजनक बनाने के लिए, --binstubs 1.0 एक विशेष ध्वज - --binstubs प्रदान करता है, जो एक बिन निर्देशिका बनाता है जिसमें यह एप्लिकेशन में उपयोग किए जाने वाले सभी रत्नों के लिए निष्पादन योग्य बनाता है। इस प्रकार, bin/cucumber चल रहा है, उदाहरण के लिए, bundle exec cucumber कमांड के बराबर है।

बिन निर्देशिका निष्पादन योग्य फ़ाइलों के लिए "पोर्टेबल" रैपर बनाता है, इसलिए आप इसे सुरक्षित रूप से रिपॉजिटरी में जोड़ सकते हैं।

rails टीम

उपरोक्त नियमों का एकमात्र अपवाद rails कमांड है। संस्करण 3.0 के साथ शुरू, यह कमांड पहले वर्तमान निर्देशिका से script/rails चलाने की कोशिश करता है। और script/rails बदले में, सबसे पहले बुंडलर शुरू करती है

 #This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application. APP_PATH = File.expand_path('../../config/application', __FILE__) require File.expand_path('../../config/boot', __FILE__) require 'rails/commands' 

boot.rb फ़ाइल की सामग्री boot.rb बदले में, बहुत nontrivial हैं:

 require 'rubygems' # Set up gems listed in the Gemfile. ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__) require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE']) 

संक्षेप में, निष्पादन योग्य rails विशेष रूप से यह सुनिश्चित करने के लिए हर संभव कोशिश करती है कि बुंडलर सैंडबॉक्स स्टार्टअप लॉजिक बहुत शुरुआत में चालू हो जाए और यदि कोई रत्न अभी भी लोड होता है तो वर्तमान प्रक्रिया को अधिभार करने के लिए Kernel#exec का उपयोग करता है।
अधिकांश एप्लिकेशन रत्नों के लिए यह व्यवहार असंभव है, और सवाल यह है कि क्या यह इस हैक का उपयोग करने के लायक है और क्या यह तथ्य कि bundle exec बिना rails को चलाया जा सकता bundle exec भी जटिल है।