Gemfile.lock फ़ाइल को समझना

181

bundle installकमांड चलाने के बाद , 'Gemfile.lock ' को वर्किंग डायरेक्टरी में बनाया गया है। उस फ़ाइल के अंदर के निर्देशों का क्या मतलब है?

उदाहरण के लिए, आइए निम्न फ़ाइल लेते हैं:

PATH
  remote: .
  specs:
    gem_one (0.0.1)

GEM
  remote: http://example.org/
  specs:
    gem_two (0.0.2)
    gem_three (0.0.3)
      gem_four (0.0.4)

PLATFORMS
  platform

DEPENDENCIES
  gem_two
  gem_one!

' PATH ', ' GEM ', ' PLATFORMS ' और ' DEPENDENCIES ' क्या वर्णन करते हैं? क्या उन सभी की आवश्यकता है?

' दूरस्थ ' और ' ऐनक ' उपनिर्देशिका में क्या होना चाहिए ?

' DEPENDENCIES ' समूह में मणि के नाम के बाद विस्मयादिबोधक चिह्न का क्या मतलब है?

ruby bundler gemfile.lock

— Shamaoke
स्रोत

71

आप इसके बारे में और अधिक जानकारी पा सकते हैं बंडल वेबसाइट (अपनी सुविधा के लिए नीचे जोड़ा गया जोर):

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

यह महत्वपूर्ण है: Gemfile.lock आपके एप्लिकेशन को आपके स्वयं के कोड और तृतीय-पक्ष कोड का एक एकल पैकेज बनाता है, यह आखिरी बार चला जब आप यह जानते हैं कि सब कुछ काम किया है। तृतीय-पक्ष कोड के सटीक संस्करणों को निर्दिष्ट करना जो आप अपने Gemfile पर निर्भर करते हैं, वही गारंटी प्रदान नहीं करेंगे, क्योंकि रत्न आमतौर पर उनकी निर्भरता के लिए कई संस्करणों की घोषणा करते हैं।

— फिलिप मिगुएल फोंसेका
स्रोत

65

यह उनके किसी भी सवाल का जवाब नहीं था, वह Gemfile.lock के प्रारूप के बारे में पूछ रहा है, लेकिन यह सिर्फ यह बताता है कि यह क्या करता है।

— जोशुआ गाल

38

विस्मयादिबोधक चिह्न के संबंध में, मुझे अभी पता चला है कि यह रत्नों के माध्यम से प्राप्त होता है :git, जैसे

gem "foo", :git => "git@github.com:company/foo.git"

— agenteo
स्रोत

वाह, अच्छा काम है कि बाहर लगाना, मुझे यह भी आश्चर्य है। धन्यवाद।

— जेपी सिल्वाशी

5

यह विकल्प के माध्यम से स्थानीय रत्नों को लोड करते समय भी होता pathहै। मैं यह अनुमान लगा रहा हूं कि एक गैर-संकलित मणि को लोड करने के साथ कुछ करना है?

— zykadelic

हाँ, यह एक कारण है। लेकिन यह एक मणि के लिए विस्मयादिबोधक बिंदु के साथ चिह्नित होने का एकमात्र कारण नहीं है। मैं वर्तमान में एक स्रोत ब्लॉक के अंदर घोषित किए गए किसी भी रत्न को विस्मयादिबोधक बिंदु के रूप में चिह्नित कर रहा हूं।

— शॉन मोबी

35

मैंने पिछले कुछ महीनों को Gemfiles और Gemfile.locks के साथ खिलवाड़ करते हुए बिताया है। एक स्वचालित निर्भरता अपडेट टूल ^{1 का} निर्माण करते हुए । नीचे निश्चित से दूर है, लेकिन यह Gemfile.lock प्रारूप को समझने के लिए एक अच्छा प्रारंभिक बिंदु है। आप बुंडलर के लॉकफाइल पार्सर के लिए स्रोत कोड की जांच भी कर सकते हैं ।

बुन्देलर १.x द्वारा बनाई गई एक तालाबंदी में आपको निम्नलिखित शीर्षक मिलेंगे:

GEM (वैकल्पिक लेकिन बहुत सामान्य)

ये एक Rubygems सर्वर से निर्भरताएं हैं। यह Rubygems.org पर मुख्य रूबीगैम इंडेक्स हो सकता है, या यह एक कस्टम इंडेक्स हो सकता है, जैसे कि जेमफ्यूरी और अन्य से उपलब्ध। इस अनुभाग के भीतर आप देखेंगे:

remote: रूबगिम्स इंडेक्स के स्थान को निर्दिष्ट करने वाली एक या अधिक लाइनें
specs: निर्भरता की एक सूची, उनके संस्करण संख्या के साथ, और किसी भी उप-निर्भरता पर बाधाओं

GIT (वैकल्पिक)

ये निर्भरताएँ किसी दिए गए गिट रिमोट से होती हैं। आपको प्रत्येक git रिमोट के लिए इन वर्गों में से एक अलग दिखाई देगा, और प्रत्येक अनुभाग के भीतर आप देखेंगे:

remote:गिट रिमोट। उदाहरण के लिए,git@github.com:rails/rails
revision: Gemfile.lock के लिए प्रतिबद्ध संदर्भ लॉक किया गया है
tag: (वैकल्पिक) जेमफाइल में निर्दिष्ट टैग
specs: इस संस्करण में पाई गई निर्भरता, इसके संस्करण संख्या और किसी भी उप-निर्भरता पर बाधाओं के साथ

पथ (वैकल्पिक)

ये एक निर्भरता है जो किसी दिए गए से pathप्रदान की जाती है, जेमफाइल में प्रदान की जाती है। आपको प्रत्येक पथ निर्भरता के लिए इन वर्गों में से एक अलग दिखाई देगा, और प्रत्येक अनुभाग के भीतर आप देखेंगे:

remote:राह। उदाहरण के लिए,plugins/vendored-dependency
specs: इस संस्करण में पाई गई निर्भरता, इसके संस्करण संख्या और किसी भी उप-निर्भरता पर बाधाओं के साथ

प्लेटफार्म

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

DEPENDENCIES

निर्भरता की एक सूची जो इसमें निर्दिष्ट की गई है Gemfile, साथ ही संस्करण की कमी भी बताई गई है।

मुख्य रूबीग्मस इंडेक्स (जैसे, जीआईटी निर्भरता, पथ-आधारित, निर्भरता) के अलावा अन्य स्रोत के साथ निर्दिष्ट निर्भरता का एक !अर्थ है कि वे उस स्रोत ^{2 पर} "पिन किए गए" हैं (हालांकि किसी को कभी-कभी यह निर्धारित करने के लिए जेमफाइल में देखना चाहिए)।

रूबी संस्करण (वैकल्पिक)

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

BUNDLED के साथ (बुंडलर> = v1.10.x)

Bundler का संस्करण Gemfile.lock का निर्माण करता था। बुंडलर के अपने संस्करण को अपडेट करने के लिए इंस्टॉलरों को याद दिलाने के लिए उपयोग किया जाता है, अगर यह फ़ाइल बनाने वाले संस्करण से पुराना है।

PLUGIN स्रोत (वैकल्पिक और बहुत दुर्लभ)

सिद्धांत रूप में, एक जेमफाइल बुंडलर प्लगइन्स, साथ ही रत्नों ³ को निर्दिष्ट कर सकता है , जिसे बाद में यहां सूचीबद्ध किया जाएगा। व्यवहार में, मुझे जुलाई 2017 तक किसी भी उपलब्ध प्लगइन्स के बारे में पता नहीं है। बुंदलर का यह हिस्सा अभी भी सक्रिय विकास के अधीन है!

— greysteil
स्रोत

2

सबसे अच्छा जवाब लगता है

— daslicious

9

बुंडलर एक रत्न प्रबंधक है जो रूबी परियोजनाओं के लिए सटीक रत्न और संस्करणों को ट्रैक करने और स्थापित करने के लिए एक सुसंगत वातावरण प्रदान करता है जिनकी आवश्यकता होती है।

Gemfile और Gemfile.lock बुंडलर रत्न द्वारा दिए गए प्राथमिक उत्पाद हैं (Bundler is a gem)।

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

Gemfile.lock में Gemfile में सभी रत्न का पूरा स्नैपशॉट होता है और इसके साथ ही निर्भरता भी होती है।

जब आप पहली बार बंडल इंस्टॉल कहते हैं , तो यह इस Gemfile.lock को बनाएगा और इस फाइल का उपयोग सभी बाद की कॉल में बंडल इंस्टॉल करने के लिए करेगा, जो यह सुनिश्चित करता है कि आपके पास सभी निर्भरताएं स्थापित हैं और निर्भरता स्थापना को छोड़ देगा।

जब आप अपना कोड अलग-अलग मशीनों के साथ साझा करते हैं तो वही होता है

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

हमें कई मशीनों के साथ निरंतरता बनाए रखने की आवश्यकता क्यों है?

विभिन्न मशीनों पर अलग-अलग संस्करण चलाने से टूटे हुए कोड हो सकते हैं
मान लीजिए, आपके ऐप ने संस्करण 1.5.3 का उपयोग किया है और यह 14 महीने पहले
बिना किसी समस्या के काम करता है, और आप
Gemfile.lock के बिना अलग मशीन पर स्थापित करने का प्रयास करते हैं। अब आपको संस्करण 1.5.8 प्राप्त होगा। हो सकता है कि यह कुछ मणि के नवीनतम संस्करण के साथ टूट गया हो और आपका आवेदन
विफल हो जाएगा । निरंतरता बनाए रखना अत्यंत महत्वपूर्ण है (पसंदीदा
अभ्यास)।

बंडल अपडेट का उपयोग करके Gemfile.lock में मणि को अद्यतन करना भी संभव है ।

यह रूढ़िवादी अद्यतन की अवधारणा पर आधारित है

— केशव
स्रोत

8

यह मुझे ऐसा लग रहा है जैसे PATH पहली पीढ़ी की निर्भरता को सीधे आपके जवाहरात से सूचीबद्ध करता है, जबकि GEM दूसरी पीढ़ी की निर्भरता (यानी आपकी निर्भरता क्या है) और आपके जेमफाइल से सूचीबद्ध करता है। PATH :: रिमोट .इसलिए है क्योंकि यह मौजूदा निर्देशिका में एक स्थानीय रत्न पर निर्भर करता है ताकि यह पता लगाया जा सके कि PATH में क्या है :: कल्पना, जबकि GEM :: Remote हैrubygems.org , क्योंकि यह वह जगह है जहाँ से यह पता लगाना है कि GEM में क्या है :: कल्पना।

रेल प्लग इन में, आपको एक PATH अनुभाग दिखाई देगा, लेकिन एक रेल एप्लिकेशन में नहीं। चूंकि ऐप में एक रत्नों की फाइल नहीं है, इसलिए PATH में डालने के लिए कुछ नहीं होगा।

DEPENDENCIES के लिए, gembundler.com बताता है:

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

rails plugin new my_pluginकुछ इसी तरह से उत्पन्न जेमफाइल :

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

इसका मतलब यह है कि अंतर क्या है

s.add_development_dependency "july" # (1)

तथा

s.add_dependency "july" # (2)

यह है कि (1) केवल एक विकास के माहौल में Gemfile.lock (और इसलिए आवेदन में) में "जूल" शामिल होगा। इसलिए जब आप दौड़ते हैं bundle install, तो आपको न केवल पाथ के तहत बल्कि DEPENDENCIES के तहत "जूल" दिखाई देगा, लेकिन केवल विकास में। उत्पादन में, यह वहाँ बिल्कुल नहीं होगा। हालाँकि, जब आप (2) का उपयोग करते हैं, तो आप "July" को केवल PATH में देखेंगे, DEPENDENCIES में नहीं, बल्कि यह तब दिखाई देगा जब आपbundle install एक उत्पादन परिवेश (यानी किसी अन्य रत्न में, जिसमें आपका एक आश्रित भी शामिल है) से नहीं, केवल विकास।

ये केवल मेरे अवलोकन हैं और मैं पूरी तरह से यह नहीं बता सकता कि इसका कोई तरीका ऐसा क्यों है लेकिन मैं आगे की टिप्पणियों का स्वागत करता हूं।

— इसहाक बेतेश
स्रोत

3

ऐसा लगता है कि Gemfile.lockप्रारूप पर बात करने वाला कोई स्पष्ट दस्तावेज़ नहीं है । हो सकता है कि यह Gemfile.lockसिर्फ आंतरिक रूप से बंडल द्वारा उपयोग किया जाता है।

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

इसके लिए GEM, यह उन सभी निर्भरताओं को सूचीबद्ध करता है जिन्हें आप प्रत्यक्ष या अप्रत्यक्ष रूप से पेश करते हैं Gemfile। remoteके तहत GEMबताता है कि रत्न कहां से प्राप्त करें, जो स्रोत द्वारा निर्दिष्ट किया गया है Gemfile।

यदि कोई रत्न नहीं मिला है remote, तो PATHउसे खोजने के लिए स्थान बताता है। जब आप निर्भरता की घोषणा करते हैं , तो PATHजानकारी पथ से आती है Gemfile।

और यहींPLATFORM से है ।

इसके लिए DEPENDENCIES, यह बंडल द्वारा हल की गई निर्भरता का स्नैपशॉट है।

— हांग
स्रोत

0

'DEPENDECIES' समूह में मणि के नाम के बाद विस्मयादिबोधक चिह्न का क्या मतलब है?

विस्मयादिबोधक चिह्न तब दिखाई देता है जब मणि को " https://rubygems.org " के अलावा किसी अन्य स्रोत का उपयोग करके स्थापित किया गया था ।

— SWiggels
स्रोत