लाइब्रेरी फोल्डर पर पैकेज मैनेजर को प्राथमिकता क्यों दें?


68

जब मैं स्टेटिक लाइब्रेरी फ़ोल्डर और पैकेज मैनेजर के पेशेवरों और विपक्षों के बारे में सोचता हूं तो मुझे लगता है कि लाइब्रेरी फ़ोल्डर एक बेहतर तरीका है।

मैं एक पुस्तकालय फ़ोल्डर के साथ देख रहा हूँ पेशेवरों:

  1. पैकेज को प्रबंधित करने के लिए किसी बाहरी उपकरण की आवश्यकता नहीं है।
  2. कोई इंटरनेट कनेक्शन बनाने की आवश्यकता नहीं है।
  3. तेज़ निर्माण (कोई पैकेज जाँच नहीं)।
  4. सरल वातावरण (कम ज्ञान की आवश्यकता)।

मैं एक पैकेज मैनेजर के साथ देख रहा हूं:

  1. जटिल निर्भरता वाले पेड़ों के साथ मदद करता है (और जो कि अपनी सभी निर्भरताओं के साथ एक निर्भरता को डाउनलोड करने में कामयाब हो सकता है)।
  2. यदि कोई नया संस्करण उपलब्ध है, तो जाँचने में मदद करता है।

ऐसा लगता है कि उद्योग ने आज निर्मित लगभग हर चीज के लिए पैकेज प्रबंधक पथ का पालन करने का फैसला किया है। तो मुझे क्या याद आ रही है?


33
मैं तुम सच में के लाभों के बारे में पूछ रहे हैं लगता है कि bundling बनाम की आवश्यकता होती है पुस्तकालयों। यदि आप उन शर्तों का उपयोग करते हैं तो आपको अधिक प्रासंगिक उत्तर मिलेंगे।
किलियन फोथ

3
आपको बिल्ड एजेंट के लिए एक डॉकटर कंटेनर बनाने से रोक रहा है, जिसमें सब कुछ आवश्यक है और संभवतः इंटरनेट एक्सेस की अनुमति भी नहीं है (जो कि भवन के लिए आवश्यक नहीं होना चाहिए)? मुझे लगता है कि आप वास्तव में तर्कों पर विचार करने की तुलना में एक नया उपकरण सीखने के खिलाफ हैं। क्या आपने कभी एक बड़ी परियोजना पर काम किया है जो हाथ से प्रबंधित निर्भरता का उपयोग करता है? यह उतना महान नहीं है जितना आप इसे बनाते हैं।
कायनात

3
@ कायमन: एक नया टूल सीखने से टीम का समय (पैसा) खर्च होता है और मैं यह सत्यापित करना चाहूंगा कि हम इसे सही चीज़ में निवेश कर रहे हैं। बड़ी परियोजनाओं के साथ मेरा अनुभव यह है कि निर्भरता काफी स्थिर है [वे लगभग कभी नहीं बदलते हैं] और शायद इसीलिए एक पैकेज मैनेजर मुझे महंगा लगता है। वैसे भी मैं सिर्फ Nuget के साथ काम करने और उसके साथ कुछ समय बिताने के बाद pro और con की सूची दे रहा था।
इग्नासियो सोलर गार्सिया

2
@sebkur आप अपने सभी पैकेजों की स्थानीय प्रतियां रख सकते हैं। हम अपने सभी निर्भरता के वर्तमान संस्करणों को स्थानीय स्रोत नियंत्रण में रखते हैं। पैकेज मैनेजर को केवल उसी समय कनेक्शन की आवश्यकता होती है जब हम अपग्रेड करते हैं।
17 की 26

1
@ 17of26: आप यह नहीं सीखते कि कैसे एक एजेंट को एनगेट स्थापित करने और इसे 10 मिनट में अनुरोध पर चलाने के लिए कॉन्फ़िगर किया जाए। न तो आप करते हैं यदि आपके पास एक बहु समाधान परियोजना है जहां एक ही परियोजनाएं विभिन्न समाधानों में उपयोग की जाती हैं।
इग्नासियो सोलर गार्सिया

जवाबों:


122

अन्य उत्तरों से गायब एक महत्वपूर्ण बिंदु:

पैकेज मैनेजर का उपयोग करने का अर्थ है कि एक कॉन्फ़िगरेशन होना जो इंगित करता है कि आप कौन से लाइब्रेरी संस्करणों का उपयोग कर रहे हैं और सुनिश्चित करें कि कॉन्फ़िगरेशन जानकारी वास्तव में सही है।

यह जानना कि आप कौन से पुस्तकालयों का उपयोग करते हैं, और कौन सा संस्करण, बहुत महत्वपूर्ण है यदि आप:

  • एक महत्वपूर्ण बग / सुरक्षा छेद के कारण पुस्तकालय को अद्यतन करने की आवश्यकता है;
  • या बस यह जाँचने की आवश्यकता है कि क्या एक घोषित सुरक्षा छेद आपको प्रभावित करता है।

इसके अलावा, जब आप वास्तव में अपडेट करते हैं, तो पैकेज मैनेजर (आमतौर पर) यह सुनिश्चित करता है कि किसी भी सकरात्मक निर्भरता को आवश्यकतानुसार अपडेट किया जाए।

जबकि एक libफ़ोल्डर के साथ , आपके पास बस (संभवतः बाइनरी, और संभवतः संशोधित) फ़ाइलों का एक गुच्छा होता है, और आपको अनुमान लगाना होगा कि वे कहाँ से आए हैं और वे किस संस्करण में हैं (या कुछ README पर भरोसा करते हैं, जो सही हो सकता है या नहीं। )।


अपने अन्य बिंदुओं को संबोधित करने के लिए:

पैकेजों को प्रबंधित करने के लिए बाहरी उपकरण की आवश्यकता नहीं है।

सही है, लेकिन क) एक सॉफ्टवेयर डेवलपर के रूप में आपको वैसे भी उपकरणों के भार को स्थापित करने की आवश्यकता है, इसलिए एक और आमतौर पर कोई फर्क नहीं पड़ता, और ख) आमतौर पर किसी भी क्षेत्र में केवल एक या कुछ पैकेज प्रबंधक होते हैं (जावा के लिए मैवेन / ग्रेड)। JS / टाइपस्क्रिप्ट, आदि के लिए npm), इसलिए ऐसा नहीं है कि आपको उनमें से दर्जनों को स्थापित करने की आवश्यकता है।

कोई इंटरनेट कनेक्शन बनाने की आवश्यकता नहीं है।

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

तेज़ निर्माण (कोई पैकेज जाँच नहीं)।

शायद सच है, लेकिन ऐसा लगता है कि ऑफ़लाइन पैकेज की जाँच में महत्वपूर्ण समय लगेगा (यह सिर्फ कुछ संस्करण संख्याओं की तुलना कर रहा है)। एक ऑनलाइन चेक में कुछ समय लग सकता है, लेकिन यदि वांछित है (यदि यह डिफ़ॉल्ट रूप से चालू है - तो उदाहरण के लिए मावेन कभी भी रिलीज़ संस्करणों के लिए अपडेट की जांच नहीं करता है)।

सरल वातावरण (कम ज्ञान की आवश्यकता)।

सच है, लेकिन जैसा कि ऊपर बताया गया है, एक libफ़ोल्डर को भी ज्ञान की आवश्यकता होती है। इसके अलावा, जैसा कि ऊपर बताया गया है, आप संभवतः केवल एक मुट्ठी भर विभिन्न पैकेज प्रबंधकों के साथ काम करेंगे, जिन्हें आप पहले से ही जानते होंगे।


170
"पैकेज को प्रबंधित करने के लिए बाहरी उपकरण की कोई आवश्यकता नहीं है" - हाँ। अब यह आपके दिमाग का काम है। सौभाग्य, मस्तिष्क!
पॉल डी। वेट

57
जो कोई भी गंभीरता से सोचता है कि एक काम करने वाला फ़ोल्डर एक "आसान वातावरण" है उसे बस आगे बढ़ना चाहिए और Microsoft.AspNetCore.All nuget के लिए निर्भरता के पेड़ का पता लगाने की कोशिश करनी चाहिए । जाओ, मेरे लिए इंतजार मत करो मैं लगभग एक दिन में वापस जाँच करूँगा।
वू

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

3
सिर्फ FYI करें, मैंने हाल ही में एक ऑफ़लाइन पीसी पर ग्रेडेल के साथ काम करने की कोशिश की है। कोई किस्मत नहीं, एंड्रॉइड स्टूडियो मेरे आवेदन को नहीं चलाएगा और मुझे एक अस्पष्ट त्रुटि संदेश मिलेगा और इसके बाद मैंने आश्रितों के लिए प्रारंभिक रन ऑनलाइन किया। यह केवल इस प्रकार की स्थितियों में होता है जब आप वास्तव में नोटिस करते हैं कि सॉफ्टवेयर बनाने वाले पैकेज मैनेजरों पर निर्भर कैसे हो जाते हैं ...
FRob

7
@ PaulD.Waite जब तक हम इस पर हैं, हम उन pesky "भाषाओं" से छुटकारा पा चुके हैं, जिनके बारे में हर कोई चल रहा है। यह सब मशीन कोड के लिए अंत में वैसे भी उबलता है, इसलिए मेरी फर्म में हमने मध्यम आदमी को काट दिया। अब वह दक्षता है!
corsiKa

39

छोटे स्तर के विकास से लेकर बड़े काम करने के बाद, लेबर फोल्डर का विकास जल्दी से गायब हो जाता है।

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

आपको पैकेज मैनेजर के लिए इंटरनेट कनेक्शन की आवश्यकता नहीं है। आप स्थानीय रिपॉजिटरी का उपयोग कर सकते हैं।

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

सरल वातावरण (कम ज्ञान की आवश्यकता)? फिर, छोटे पैमाने पर विकास में निश्चित रूप से एक संभावना है। आप उपयोग किए जा रहे कुछ पुस्तकालयों में से प्रत्येक के लिए पूरी तरह से अपने सिर में परियोजना को धारण करने में सक्षम हो सकते हैं। एक साधारण मेकफाइल / अन्य बिल्ड स्क्रिप्ट जोड़ें और आप अपने आप को एक पूर्ण पैकेज मिला है।

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


21
@IgnacioSolerGarcia: यह केवल आसान है अगर कुछ भी गलत न हो। क्या होगा अगर लाइब्रेरी ए के नए संस्करण को अपडेटेड बी और सी की भी जरूरत है? यदि आप अभी भी इसे चलाते हैं तो क्या होगा, लेकिन सूक्ष्म कीड़े का परिचय देता है। यह सब "निर्भरता के प्रबंधन" का हिस्सा है।
सालेके

18
@IgnacioSolerGarcia का कहना है कि "एक फ़ाइल डाउनलोड करें" काफी सही तस्वीर को चित्रित नहीं करता है। मान लें कि "20 फाइलें डाउनलोड करें और सुनिश्चित करें कि उनके संस्करण संगत हैं"। वहां कोई काम टाला नहीं गया। संकुल को अद्यतन करना एक सैद्धांतिक स्थिति नहीं है, जब तक कि आपने निर्भरता संस्करणों को स्थिर करने का निर्णय नहीं लिया है और उससे होने वाले संभावित मुद्दों (बग, सुरक्षा खामियों) को स्वीकार करने के लिए तैयार हैं।
कायनात

12
@IgnacioSolerGarcia "एक फ़ाइल डाउनलोड करें" - क्या आपका मतलब है (1) सही प्रोजेक्ट वेबसाइट ढूंढें (कुछ गिथब पर होस्ट किए गए हैं, कुछ सोर्सफोर्गे पर, कुछ अपनी वेबसाइट पर), (2) डाउनलोड पेज पर जाएं, (3) सही संस्करण खोजें , (4) डाउनलोड, (5) अनज़िप करें और कहीं छोड़ दें। की तुलना में बहुत अधिक काम लगता है blah install libfoo। और फिर, उस पर, कहो, 5 निर्भरता को गुणा करें।
el.pescado

5
@IgnacioSolerGarcia ठीक है जो फ़ाइलें मैं "बस" इस nuget सही ढंग से काम करने के लिए डाउनलोड करने के लिए है ? और वह मूल रूप से ASP.NET कोर परियोजना के लिए सबसे तुच्छ सेटअप है। व्यवहार में आपके पास कई और निर्भरताएँ होंगी।
वू

6
@Ignacio यह सबसे सरल ASP.Net कोर एप्लिकेशन को चलाने और चलाने के लिए मूल मेटा नगेट है। पूरे ढांचे के अच्छे पुराने दिनों में यह पूरी तरह से "आसान" था, क्योंकि आपको सिर्फ बड़े अखंड पुस्तकालय मिले थे, जो एक ही समय में सभी संस्करण थे और एक अद्यतन जारी करने में आपको वर्षों लग गए। उस मॉडल को मूल रूप से बहुत अच्छे कारणों से केवल .NET दुनिया में नहीं मिला। आपको बहुत सारे छोटे पुस्तकालयों के पूरे मॉडल के लिए उपयोग करना होगा, एक विशेष बात और ईमानदारी से एक पैकेज प्रबंधक का उपयोग करना संक्रमण का सबसे आसान हिस्सा है।
वू

35

आपको पैकेज मैनेजर के कई फायदे याद आ रहे हैं ।

  1. पैकेज प्रबंधक आपको बड़े (कई मेगाबाइट या बड़े) बायनेरिज़ को स्रोत नियंत्रण में जाँचने से बचने की अनुमति देते हैं। ऐसा करना कई स्रोत नियंत्रण साधनों के प्रति अरुचि है, उनमें से एक है। हमारे पास कुछ महीने पहले बिट बकेट के आकार की एक रिपॉजिटरी हिट थी, क्योंकि कोकोआपॉड में डेवलपर्स जाँच कर रहे थे। एक अन्य परियोजना पहले से ही आधी थी जब हमने एसवीएन से पलायन किया था क्योंकि हम अपने सभी काम के बायनेरिज़ में जाँच कर रहे थे (और नूगेट का उपयोग नहीं कर रहे थे)। चूंकि पैकेज मैनेजर प्रत्येक डेवलपर के लिए मक्खी पर पैकेज डाउनलोड करेंगे, इसलिए वे इन बायनेरिज़ की जांच करने की आवश्यकता को समाप्त कर देते हैं।
  2. वे असंगत फ़ाइलों / पुस्तकालयों को मिलाने से रोकते हैं। फ़ोल्डर में लाइब्रेरी की फ़ाइलों के मिश्रित संस्करण हो सकते हैं यदि कोई अपग्रेड के दौरान इसे ठीक से साफ नहीं करता है। मैंने एक मामला देखा है जहां फ़ोल्डर में आधे बायनेरिज़ को अपग्रेड किया गया था, जिसके परिणामस्वरूप बहुत ही अजीब कीड़े थे। (यह भी दुर्घटना नहीं हुई!) इस समस्या का पता लगाने के लिए हमें सचमुच महीने (आदमी घंटे नहीं, बस समग्र समय) लग गए। पैकेज प्रबंधक को संपूर्ण फ़ोल्डर को नियंत्रित करने देने से, आपको मिश्रित संस्करण नहीं मिल सकते हैं; आप निरंतरता सुनिश्चित करते हैं। वे असंगत निर्भरता का उपयोग करने के लिए बहुत कठिन बना देते हैं , स्वचालित रूप से सब कुछ एक साथ अपडेट करके, विभिन्न संस्करणों को स्थापित करना, जहां आवश्यक हो, या यहां तक ​​कि पुस्तकालयों के असंगत संस्करणों का उपयोग करने का प्रयास करते समय केवल चेतावनी या त्रुटियों को फेंकना।
  3. वे पुस्तकालयों के प्रबंधन के लिए एक साझा सम्मेलन की स्थापना करते हैं। जब नए डेवलपर आपके प्रोजेक्ट, टीम, कंपनी इत्यादि पर आते हैं, तो उन्हें पैकेज मैनेजर के सम्मेलनों की जानकारी होगी। इसका मतलब है कि उन्हें इस बात का ठीक से पता लगाने की ज़रूरत नहीं है कि आपके कोड आधार में पुस्तकालयों का प्रबंधन कैसे किया जाता है।
  4. वे आपको अपनी स्वयं की निर्भरता और फ़ाइलों को संस्करण और वितरित करने का एक मानक तरीका देते हैं जो आपके भंडार में नहीं हैं। मैंने अपने व्यक्तिगत रूप से कुछ बड़ी स्थिर डेटा फ़ाइलों के लिए भी उनका व्यक्तिगत रूप से लाभ उठाया है, इसलिए यह बाइनरी कोड के अलावा चीजों के संस्करण के लिए अच्छी तरह से काम करता है।
  5. कुछ पैकेज प्रबंधक स्थापना के दौरान अतिरिक्त सुविधाएँ प्रदान करते हैं। NuGet आपकी csproj फ़ाइल में निर्भरता और सामग्री फ़ाइलों को जोड़ देगा और कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगरेशन तत्व भी जोड़ सकता है।
  6. उनकी पैकेज सूची एक एकल, केंद्रीकृत जगह में आपके पुस्तकालयों के संस्करणों का दस्तावेज बनाती है। मुझे DLL पर राइट क्लिक करने की जरूरत नहीं है और संस्करण संख्या को देखने के लिए यह पता लगाएं कि मैं किस लाइब्रेरी का उपयोग कर रहा हूं। पायथन में, लाइब्रेरी लेखक ने पाई फ़ाइलों में संस्करण संख्या को शामिल नहीं किया होगा, इसलिए मैं उनसे लाइब्रेरी संस्करण भी नहीं बता सकता।
  7. वे मशीन निर्भरता की व्यापक स्थापना को हतोत्साहित करते हैं। पैकेज प्रबंधक वैश्विक इंस्टॉलर के बिना निर्भरता स्थापित करने का एक पारंपरिक तरीका प्रदान करते हैं । जब आपके विकल्प lib फ़ोल्डर और वैश्विक स्थापना होते हैं, तो कई लाइब्रेरी डेवलपर अपने पुस्तकालयों को वैश्विक इंस्टॉलेशन के रूप में डाउनलोड करने योग्य बायनेरिज़ के रूप में पेश करने का चयन करेंगे, जिन्हें आपको स्वयं स्थापित करना होगा। (एमएस इतिहास यह प्रदर्शित करता है। यह लिनक्स के कई पुस्तकालयों के लिए भी मामला है।) यह वास्तव में कई परियोजनाओं को प्रबंधित करना अधिक कठिन बना देता है, क्योंकि आपके पास परस्पर विरोधी संस्करणों के साथ परियोजनाएं हो सकती हैं और कुछ डेवलपर्स निश्चित रूप से अपने स्वयं के काम करने के लिए प्रतीत होता है कि सरल वैश्विक स्थापित का चयन करेंगे। dir।
  8. वे होस्टिंग और वितरण को केंद्रीकृत करते हैं। अब आपको उस यादृच्छिक लाइब्रेरी की वेब साइट पर निर्भर नहीं रहना पड़ेगा। यदि वे व्यवसाय से बाहर जाते हैं, तो एक सफल पैकेज मैनेजर की साइट पर अभी भी हर संस्करण अपलोड है। डेवलपर्स को भी नए पुस्तकालयों को डाउनलोड करने के लिए कई वेब साइटों का शिकार नहीं करना पड़ता है; उनके पास पहले देखने के लिए और यहां तक ​​कि विभिन्न विकल्पों के लिए ब्राउज़ करने के लिए एक जगह है। एड-हॉक वेबसाइटों की हर चीज़ की प्रतियों को मैन्युअल रूप से होस्ट करने की तुलना में एक मानक तरीके से आयोजित दर्पण पैकेजों के लिए भी आसान है।

आप अपने "लाभ" के मूल्य को भी कम कर रहे हैं।

  1. पैकेजों को प्रबंधित करने के लिए बाहरी उपकरण की आवश्यकता नहीं है।

    "बाहरी" क्या? मैं अपने रिपॉजिटरी में निष्पादन योग्य NuGet की जांच करता हूं। यह केवल द्विआधारी है जो मुझे ठीक से जांचने में लगता है, क्योंकि यह छोटा है और इसका मतलब है कि मुझे किसी अन्य बायनेरी की जांच करने की आवश्यकता नहीं है।

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

    जब तक वे व्यापक रूप से अपनाते हैं, तब तक पैकेज मैनेजर बहुत स्थिर हो जाते हैं। आप बिना दूर नहीं मिल सकता है कुछ सबसे परियोजनाओं के लिए विश्व स्तर पर स्थापित टूलींग की तरह, और एक एकल पैकेज प्रबंधक एक बहुत हल्के वजन आवश्यकता है। यह आमतौर पर भाषा रनटाइम स्थापित होने की तुलना में बहुत अधिक बोझिल नहीं है।

  2. कोई इंटरनेट कनेक्शन बनाने की आवश्यकता नहीं है।

    मैं नेटवर्क कनेक्शन के बिना अपने डेटाबेस से कनेक्ट नहीं कर सकता। यदि डेटाबेस अमेज़ॅन होस्ट किया गया है, तो मुझे वैसे भी पूर्ण इंटरनेट कनेक्शन की आवश्यकता है। मुझे स्रोत नियंत्रण के माध्यम से परिवर्तनों को धकेलने और खींचने के लिए इंटरनेट कनेक्शन की आवश्यकता है; एक बिल्ड सर्वर कुछ प्रकार के नेटवर्क कनेक्शन के बिना निर्माण के लिए कोड की जांच नहीं कर सकता है। आप एक के बिना ई-मेल भेज या प्राप्त नहीं कर सकते । आप एक के बिना अपने काम के फ़ोल्डर में डालने के लिए पुस्तकालयों को डाउनलोड नहीं कर सकते हैं! इंटरनेट कनेक्शन के बिना स्थायी रूप से विकसित होना वास्तव में अनसुना है। कुछ दुर्लभ मामलों में जहां यह आवश्यक है, आप पैकेज को उस स्थान पर डाउनलोड करके इससे निपट सकते हैं जिसे पैकेज प्रबंधक उपभोग कर सकता है। (मुझे पता है कि नुगेट और पाइप एक साधारण फ़ोल्डर या नेटवर्क ड्राइव से खींचने के लिए काफी खुश हैं; मुझे संदेह है कि अधिकांश अन्य भी कर सकते हैं।)

  3. तेज़ निर्माण (कोई पैकेज जाँच नहीं)।

    स्वचालित निर्माण के दौरान 30 सेकंड और स्थानीय देव बिल्ड के दौरान 5 सेकंड मैं ऊपर उल्लिखित लाभों के लिए एक अच्छा व्यापार है। ये तुच्छ समय के तख्ते हैं जो आमतौर पर उन लाभों की तुलना में विचार करने के लायक नहीं हैं जो लाभ हल करते हैं।

  4. सरल वातावरण (कम ज्ञान की आवश्यकता)।

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

सामान्य विषय यह है कि वे न केवल परियोजनाओं के भीतर, बल्कि उनके पार भी निरंतरता, प्रलेखन और सुविधाएँ प्रदान करते हैं। यह हर किसी के जीवन को सरल बनाता है।


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

1
यद्यपि आपका अपना बुनियादी ढांचा वास्तव में उन कुछ चीजों में से एक है जो किसी भी मामले में समझ में आता है: आप बाहरी बुनियादी ढांचे पर विश्वसनीय नहीं होना चाहते हैं। यदि वह एक कारण से उपलब्ध नहीं है या किसी अन्य के पास कमबैक करना बेहतर है जो गारंटी देता है कि आपके डेवलपर्स का विकास जारी रह सकता है। (और इससे पहले कि कोई मुझे बताए कि कैसे nuget.org या npm या <पसंदीदा पैकेज डालें रेपो> कभी भी इस तरह की परेशानी नहीं होगी, शायद फिर से सोचें ।)
वू

3
@IgnacioSolerGarcia एक परियोजना या प्रति विभाग या प्रति कंपनी सम्मेलन की स्थापना केवल एक सम्मेलन होने के बिना सभी को बताए जाने से बेहतर नहीं है। इसके अतिरिक्त, पैकेज प्रबंधन , सम्मेलन को लागू करने का एक बेहतर काम करता है , क्योंकि यह सम्मेलन को तोड़ने से कम काम का पालन करता है। इसके अलावा, जैसा कि मैंने उल्लेख किया है, मैं सीधे NuGet प्रतिबद्ध करता हूं और इसे बिल्ड स्क्रिप्ट में लागू करता हूं, इसलिए मुझे इसे स्थापित करने की आवश्यकता नहीं है। मैं सर्वर की स्थापना को वास्तव में नंगे न्यूनतम रखता हूं।
jpmc26

2
@ jpmc26 Imho आपकी पहली गिने जाने वाली सूची को कुछ जोर देने से फायदा होगा ।
सोरेन डी। Pt Junus

1
@ SørenD.Ptæus हो गया।
jpmc26

16

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

हमारे उत्पाद को 27 सी # परियोजनाओं में लागू किया गया है, जो आज के मानकों से अपेक्षाकृत छोटा है। हमारी तीसरी पार्टी पर निर्भरता में दर्जनों विधानसभाएं हैं।

Nuget से पहले, अगर मैं अपने सभी निर्भरता को नवीनतम संस्करण में अपडेट करना चाहता था, तो मुझे करना होगा:

  1. नीचे ट्रैक करें जहां मुझे सभी अपडेट किए गए लाइब्रेरी मिल सकते हैं
  2. उन्हें डाउनलोड करें और अनज़िप / इंस्टॉल करें
  3. स्रोत नियंत्रण में नए संस्करण जोड़ें
  4. हमारी परियोजनाओं में सभी संदर्भों को मैन्युअल रूप से देखें और उन्हें नई विधानसभाओं की ओर इंगित करने के लिए अपडेट करें

27 परियोजनाओं और दर्जनों निर्भरता विधानसभाओं के साथ, इस प्रक्रिया में बहुत त्रुटि थी और इसमें घंटों लग सकते थे।

अब जब हमने Nuget का उपयोग करने के लिए अपडेट कर दिया है, तो यह सब मेरे लिए एक ही आदेश के साथ किया गया है।


सहमत हूँ, कि समर्थक के बिंदु 2 है। वैसे भी बदलती निर्भरता एक ऐसी चीज है जिसे हम शायद ही कभी करते हैं (शायद उचित ऑटोमेशन प्रतिगमन परीक्षणों की कमी के कारण)।
इग्नासियो सोलर गार्सिया

9
निर्भरता को अद्यतन करना कुछ ऐसा है जो बहुत कम दर्दनाक है अगर आप इसे नियमित रूप से करते हैं।
17 की 26

1
क्या ये परीक्षण स्वचालित हैं? वास्तव में उन्हें चलाने में कितना समय लगता है? यहां तक ​​कि अगर परीक्षणों के पूर्ण सूट को चलाने के लिए 24 घंटे लगते हैं, तो भी यह आपको थोड़े से नकारात्मक परिणामों के साथ हर कुछ दिनों में निर्भरता को अपडेट करने की अनुमति देता है (भले ही आप शायद ऐसा नहीं करेंगे जो अक्सर अभ्यास में होता है)। यहां तक ​​कि अगर वे मैनुअल और अपरिहार्य हैं, तो मैन्युअल इंस्टॉलेशन का उपयोग करके आप परीक्षण के माध्यम से चलने वाले दिन केवल यह पता लगाने के लिए बिता सकते हैं कि वे विफल हो गए क्योंकि आप एक निर्भरता के कुछ निर्भरता से चूक गए, तो आपको इसे स्थापित करने के बाद फिर से शुरू करना होगा, जो नहीं होगा पैकेज प्रबंधन का उपयोग ...
शॉन बर्टन

3
क्या आपको नए सॉफ़्टवेयर रिलीज़ पर प्रतिगमन परीक्षणों की आवश्यकता नहीं है? जब आप पहले से ही रिलीज़ के लिए परीक्षण कर रहे हों तो निर्भरता को अपडेट करें।
17 की 26

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

14

पैकेजों को प्रबंधित करने के लिए बाहरी उपकरण की आवश्यकता नहीं है

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

कोई इंटरनेट कनेक्शन बनाने की आवश्यकता नहीं है

इसके अलावा आज के समय में इंटरनेट कनेक्शन न होना कुछ हद तक दुर्लभ है (हो सकता है कि पारगमन के अपवाद के साथ), एक सभ्य पैकेज प्रबंधक को आपके आवेदन के निर्माण के लिए नवीनतम संस्करण होने की आवश्यकता नहीं होनी चाहिए। यह शिकायत कर सकता है, लेकिन इसके पहले से इंस्टॉल किए गए संस्करण के साथ निर्माण नहीं करने का कोई कारण नहीं है

तेज़ निर्माण (पैकेज जाँच नहीं)

यह एक बहुत ही मामूली स्पीडबॉस्ट है, लेकिन आप यकीनन इसके लिए एक बिंदु बना सकते हैं।

सरल वातावरण (कम ज्ञान की आवश्यकता)

अधिकांश पैकेज प्रबंधक इन दिनों इतने सरल हैं कि ऐसा करने से उनके आसपास पाने की कोशिश करना मुश्किल है। यदि आप चाहते हैं तो दृश्य ग्राहक भी हैं। वे वास्तव में चल रहे क्रॉफ्ट को बहुत छिपाते हैं।

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

एक लीबर फ़ोल्डर के साथ आप केवल उस प्रोजेक्ट के लिए पैकेज का प्रबंधन करते हैं, जबकि एक पैकेज मैनेजर आपको एक एकल टूल के साथ आपके संपूर्ण विकास परिवेश के लिए ऐसा करने की अनुमति देता है।


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

4
मुझे लगता है कि यह निर्भर करता है कि आप किस भाषा / भाषा का उपयोग कर रहे हैं। रूबी या जंग जैसी भाषाओं के साथ पैकेज-प्रबंधन इतनी अच्छी तरह से एकीकृत है कि इसका उपयोग करना पूरी तरह से तुच्छ है।
सीन बर्टन

खैर, मुझे लगता है कि व्यापक टिप्पणी करने के उद्देश्य से, लेकिन मैं विशेष रूप से NuGet, C # और VSTS क्लाउड के बारे में बात कर रहा हूं।
इग्नासियो सोलर गार्सिया

4
@Ignacio आप जो भी निर्माण प्रणाली का उपयोग कर रहे हैं वह NuGets को पुनर्स्थापित करने के लिए पूरी तरह से तुच्छ नहीं बनाता है इसे तुरंत बाहर फेंक दिया जाना चाहिए। सौभाग्य से VSTS इसे जितना आसान हो जाता है ( प्रलेखन ) के बारे में बनाता है : एक NuGet पुनर्स्थापना कार्य है जो आप अपनी समाधान फ़ाइल को इंगित करते हैं और यह बताते हैं कि NuGet स्रोतों का उपयोग करने के लिए क्या है - एक साधारण परियोजना के लिए बस का उपयोग nuget.orgकरना ठीक होगा (डिफ़ॉल्ट टेम्पलेट चाहिए पहले से ही इस तरह से स्थापित किया जा रहा है)।
वू

3
@ बॉन आरवीएम एक पैकेज मैनेजर नहीं है। रूबी के लिए पैकेज मैनेजर रूबीजीम्स है। आरवीएम खुद रूबी के संस्करणों का प्रबंधन करता है, और इसके लिए रेंबव बेहतर है ...
सीन बर्टन

5

यह सिर्फ बीच का अंतर है का उपयोग कर पुस्तकालयों (lib निर्देशिका) , और उन्हें प्रयोग करने, बनाए रखने मेटा जानकारी (पैकेज प्रबंधक) । पुस्तकालयों और इस तरह के बीच मेटा-सूचना चिंताओं संस्करण संख्या, (सकर्मक) निर्भरता।

DLL नरक, पुस्तकालय अनुकूलता, जावा मॉड्यूल प्रणाली, OSGi और इस तरह की चर्चा कम से कम निर्भरता प्रबंधन के कुछ फार्म होने के कुछ मूल्य के पर्याप्त आश्वस्त होना चाहिए।

  • लाइब्रेरी संस्करण और निर्भरता की समस्याएं समय की बर्बादी हो सकती हैं।

इसके अलावा एक साझा (स्थानीय) भंडार का लाभ भी है, इसलिए कई परियोजनाओं को आयातित कामों की प्रतियां बनाए रखने की आवश्यकता नहीं है। यदि किसी के पास 20 सबमॉड्यूल के साथ एक परियोजना है, तो उनमें से कुछ मॉड्यूल में 40 विषम निर्भरताएं हैं।

  • अधिक संरचना
  • पुस्तकालयों की अधिक ट्रिमिंग
  • पुस्तकालयों के बारे में कोई तदर्थ मानव निर्णय नहीं

3

कुछ मामले हैं जहां एक उदाहरण के लिए एक आवश्यक फ़ोल्डर आवश्यक हो सकता है, जब अप्रचलित पुस्तकालयों के साथ काम करते हुए (इसका एक संस्करण अब बनाए रखा / उपलब्ध नहीं है), एक पुस्तकालय का स्थानीय रूप से संशोधित संस्करण, ...

लेकिन बाकी सभी चीजों के लिए, यह डेवलपर की तरह है जो पैकेज मैनेजर की भूमिका निभाता है:

  • डेवलपर को पुस्तकालय (इंटरनेट आवश्यक) डाउनलोड करना होगा
  • डेवलपर को मैन्युअल रूप से नए रिलीज के लिए जांचना होगा
  • ...

और IMHO, यह कम ज्ञान की आवश्यकता है, क्योंकि आपको बाहरी उपकरण के उपयोग के बारे में सीखना है, लेकिन पुस्तकालयों (यानी आश्रित) के बारे में कम है।


4
यहां तक ​​कि अप्रचलित या संशोधित पुस्तकालयों के लिए, मैंने अब तक जो भी पैकेज मैनेजर देखे हैं, वे आपके स्थानीय भंडार के लिए स्थानीय निर्भरता को अपलोड करने का विकल्प प्रदान करते हैं। लेकिन ठीक है, यह वह जगह है जहाँ आप कुछ "यह अपने आप काम करता है" अनुभव को ढीला कर देता है।
हल्क

@Hulk अगर यह एक ओपन सोर्स लाइब्रेरी है तो आप (और, शायद) अपने संस्करण को प्रकाशित कर सकते हैं और इस तरह इसे पैकेज मैनेजर को दिखा सकते हैं। या तो संशोधनकर्ताओं को धक्का देकर, या पुस्तकालय के अपने स्वयं के कांटे को बाहर लाकर।
लेफ्टरनबाउट

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

1

अन्य प्रश्नों द्वारा कवर नहीं की गई एक और समस्या है: शेयरिंग डिप्स।

मान लीजिए, आपके पास एक ही लाइब्रेरी बनाने वाले दो पैकेज हैं । सबसे अच्छी स्थिति में, कोई कॉफ़्लिस नहीं होगा, लेकिन एक ही एचडीडी / एसएसडी स्पेस दो बार उपयोग किया जाएगा। सबसे खराब स्थिति में, संस्करणों की तरह वैरिएस संघर्ष होंगे।

यदि आप पैकेज मैनेजर का उपयोग करते हैं, तो यह केवल एक बार (प्रति संस्करण) लाइब्रेरी स्थापित करेगा और पहले से ही इसे पथ प्रदान करेगा।

पुनश्च: बेशक, आपको इस प्रो को प्राप्त करने के लिए गतिशील लिंकेज (या आपकी भाषा में समान कार्य) की आवश्यकता है।


-5

साझा पुस्तकालयों को 90 के दशक के यूनिक्स और विंडोज सिस्टम में प्रगति का एक प्रमुख कारण माना जाता था कि कैसे पुस्तकालयों के एक ही सेट का उपयोग कर कई कार्यक्रमों को लोड किए जाने पर वे रैम का उपयोग कम कर सकते थे। कोड स्थान को केवल सही पुस्तकालय और उस पुस्तकालय के संस्करण पर ONCE आवंटित करने की आवश्यकता है , शेष प्रति-मेमोरी मेमोरी उपयोग केवल स्थिर चर के लिए है।

कई ऑपरेटिंग सिस्टम साझा पुस्तकालयों को इस तरह से लागू करते हैं जो यूनिक्स एमएमएपी () एपी जैसे तंत्रों पर निर्भर करते हैं - जिसका अर्थ है कि एक पुस्तकालय को केवल एक ही संस्करण होने की आवश्यकता नहीं होगी, लेकिन वास्तव में बहुत ही समान फ़ाइल। यह केवल एक प्रोग्राम के लिए पूर्ण लाभ उठाना असंभव है जो पुस्तकालयों के अपने सेट को जहाज करता है।

यह देखते हुए कि स्मृति अब तक सस्ती है, और लाइब्रेरी संस्करणों को 90 के दशक की तुलना में अधिक विविध की आवश्यकता है, यह तर्क आज उतना वजन नहीं उठाता है।


4
यह सवाल साझा पुस्तकालयों के बारे में बात नहीं करता है लेकिन एक पुस्तकालय फ़ोल्डर पर निर्भरता है।
इग्नासियो सोलर गार्सिया

1
यह ओपी के सवाल का जवाब नहीं देता है
esoterik
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.