वैकल्पिक पैकेज प्रबंधकों के उपयोग के मामले क्या हैं?

Question

पृष्ठभूमि

मैं रोजाना इमेक का उपयोग करता हूं, लेकिन ज्यादातर चीजों को प्राप्त करने के लिए। मुझे वास्तव में पैकेज जोड़ने से अधिक इसे अनुकूलित करना पसंद नहीं है और मुझे समस्या निवारण पसंद नहीं है। मैं चाहता हूं कि एमएसीएस पृष्ठभूमि में फीका हो जाए जिस तरह से एक अच्छा ओएस करता है और बस चीजों के साथ मिलता है। कुछ समय पहले मैंने पाया कि el-getमुझे उन पैकेजों को स्थापित करने की अनुमति दी, जिनकी मुझे आवश्यकता थी, जो अनुपलब्ध थे package.elऔर साथ ही मुझे अधिक नियंत्रण भी दिया जैसे maintकि ब्लीडिंग एज के बजाय ऑर्ग-मोड की शाखा का चयन करना जो अस्थायी समस्या पैदा कर सकता है। अब मुझे यकीन नहीं है कि मुझे इस्तेमाल करना चाहिए el-getया नहीं।

सवाल

el-getलगता है कि विभिन्न रिपॉजिटरी और ईमैक्स हैक के लिए एक महान समाधान है। इसने उन क्षमताओं की पेशकश की जो संभव नहीं थी package.el। अब जब कि package.elemacs के नए संस्करणों में ( >=24.4) कई रिपॉजिटरी का समर्थन करता है, तो el-getemacs के बिल्ट-इन पैकेज मैनेजर के लिए और इसी तरह के विकल्पों के लिए उपयोग के मामले क्या हैं ?

Comments

यह भी देखें: quelpa । संक्षिप्त उत्तर है: निश्चित रूप से यह है, अभी भी ऐसे पैकेज हैं जो ELPA / MELPA / मुरब्बा पर नहीं हैं। यदि आप पाते हैं कि आपको एक की आवश्यकता है, तो आप अभी भी इसे भयानक हैक के साथ el-getऔर पसंद के बिना प्राप्त कर सकते हैं।

— अजगर

Answer 1

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

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

यदि आपको ELPA से परे की विशेषताओं की आवश्यकता है, तो आपको el-get की बजाय QUELPA को देखना चाहिए।

Comments

"अगर वे कोई भी नहीं था अभी भी उन्हें बनाए रखने के लिए परेशान नहीं करेगा।" उद्देश्य केवल डेवलपर का अहंकार हो सकता है, हालांकि।

— टी। वेरॉन

यह एक शक्तिशाली अहंकार होगा, हालाँकि, यह आसानी से बड़े समुदाय के रूप में आकर्षित हो सकता है क्योंकि अभी भी एल-गेटा है, और क्वेलपीए जल्दी ही :) :)

— चंद्र

मैं सामान्य तौर पर टिप्पणी कर रहा था। ;)हाथ पर संकुल की बारीकियों के लिए, आपका उत्तर, सामान्य ज्ञान कथन से परे, एल-गेट और क्वेलपा के उद्देश्य को प्रदर्शित करके एक मजबूत बिंदु बनाता है।

— टी। वेरॉन

@ टी। वेरॉन येप, पॉइंट लिया गया। मैंने वह बयान हटा दिया है, यह कहना बेवकूफी थी। माफ़ करना।

— चंद्र

आपके साथ @lunaryorn का el-get, however, does not expose its own packages to ELPA, meaning that **its packages** are entirely invisible to ELPA and ELPA मतलब है एल- गेट द्वारा स्थापित चीजें, सही?

— toogley'

Answer 2

मैंने Emacs के लिए एक नया पैकेज मैनेजर लिखा है straight.el, जो सभी मौजूदा पैकेज प्रबंधन समाधानों में सुधार करने का प्रयास करता है। अन्य पैकेज प्रबंधकों की तुलना के बारे में दस्तावेज में एक व्यापक खंड है , लेकिन यहां एक बहुत ही संक्षिप्त सारांश है:straight.el

• package.elकेंद्रीय सर्वर से अपारदर्शी टारबॉल डाउनलोड करता है, जिसमें पैकेज के विशिष्ट संस्करण का चयन करने का कोई विकल्प नहीं होता है, और आपको अपने पैकेजों में स्थानीय परिवर्तन करने की अनुमति नहीं देता है; अपस्ट्रीम में बदलाव का योगदान असंभव है। straight.elक्लोन विकेंद्रीकृत तरीके से रिपॉजिटरी (लेकिन यह स्वचालित रूप से MELPA , GNU ELPA , और EmacsMirror से व्यंजनों का उपयोग करता है , यदि आप चाहें), और आप उन्हें मनमाने ढंग से स्थानीय परिवर्तन करने, उन परिवर्तनों को करने और अपस्ट्रीम योगदान करने की अनुमति देते हैं। यह मैन्युअल रूप से किया जा सकता है, या आप अंतर्निहित बल्क रिपॉजिटरी प्रबंधन संचालन का उपयोग कर सकते हैं। आपके पैकेज में परिवर्तन स्वचालित रूप से पाए जाते हैं, और मैनुअल रीबिल्ड की आवश्यकता नहीं होती है। इसके अलावा,straight.el आपके Emacs कॉन्फ़िगरेशन के लिए पूर्ण प्रतिलिपि प्रस्तुत करने योग्यता का समर्थन करता है, क्योंकि यह आपको एक संशोधन लॉकफ़ाइल लिखने की अनुमति देता है जिसमें आपके सभी पैकेजों के गिट हैश शामिल हैं।
• क्वेलपा और पीपा दोनों पर आधारित हैं package.el, और एक ही नुकसान के कई विरासत हैं। उदाहरण के लिए, किसी पैकेज के किसी विशेष संस्करण को स्थापित करने की कोई अवधारणा नहीं है। Quelpa करता है, लेकिन इसके लिए आवश्यक है कि आप अपनी init-file में Git हैश को हार्डकोड करें। पूरी तरह से straight.elबच जाता है package.el, इसकी कोर कार्यक्षमता की जगह एक एकीकृत डिजाइन के साथ कई और अधिक उपयोग मामलों के अनुरूप है।
• el-get का फायदा है कि आप संकुल को हर जगह (सभी ज्ञात संस्करण-नियंत्रण प्रणाली, मनमाना HTTP, सिस्टम पैकेज प्रबंधक, EmacsWiki, यहां तक ​​कि go get!) से स्थापित कर सकते हैं। हालाँकि, इतने सारे स्रोतों का समर्थन करने के बाद, एल-गेट उन्नत पैकेज प्रबंधन संचालन (जैसे संशोधन लॉकफ़ाइल्स और इंटरएक्टिव रिपॉजिटरी प्रबंधन संचालन के माध्यम से प्रतिलिपि प्रस्तुत करने योग्य) straight.elप्रदान नहीं कर सकता है। straight.elकेवल Git का समर्थन करता है, क्योंकि अधिकांश पैकेज Git के माध्यम से उपलब्ध होते हैं और जो EmacsMirror के माध्यम से प्राप्त नहीं किए जा सकते हैं (मैं आपको एक खोजने की हिम्मत करता हूं जो ऐसा नहीं हो सकता है!)। ध्यान दें कि straight.elफिर भी अतिरिक्त संस्करण-नियंत्रण बैकेंड (उदाहरण के लिए मर्क्यूरियल) के लिए एक एक्स्टेंसिबल एपीआई प्रदान करता है, यदि वांछित हो तो भविष्य में जोड़ा जा सकता है।
• बोर्ग का एक समान दर्शन है straight.elऔर इससे कई फायदे मिलते हैं । हालांकि, यह एक पूर्ण पैकेज प्रबंधक होने के लिए नहीं बनाया गया है, और इस तरह के रूप में अन्य उपकरणों के साथ चिंता का विषय में इस्तेमाल किया जा बनाया गया है epkg, auto-compileऔर MAGIT। इसके विपरीत, straight.elस्व-निहित है और आपको जो कुछ भी अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है, वह सब कुछ प्रदान करता है। इसके अलावा, बोर्ग Git सबमॉड्यूल्स का उपयोग करता है, जिसके इंटरफ़ेस में कुछ खुरदरे किनारे हैं, जबकि straight.elअतिरिक्त लचीलेपन और शक्ति का उपयोग करते हुए स्वतंत्र रूप से प्रबंधित Git रिपॉजिटरी का उपयोग करता है।
• वहाँ भी मैनुअल दृष्टिकोण है, लेकिन मैं यह सिफारिश नहीं है। पहले कुछ महीनों के बाद, आपने बोर्ग को फिर से स्थापित किया होगा। फिर अगले कुछ महीनों के बाद, आप फिर से संगठित हो गए होंगे straight.el। आप पैकेज प्रबंधन के बारे में बहुत कुछ सीखेंगे, हालाँकि;)

Answer 3

जबकि पेशेवरों और विपक्ष हैं, मुझे लगता है कि @lunaryon (rejeep) की मजबूत राय के बावजूद, el-get अभी भी प्रासंगिक है।

मैंने कुछ समय (2 से 3 साल) के लिए उपयोग के साथ कच्चे package.el का उपयोग किया , फिर el-get , फिर Cask पर स्विच किया । मैं कुछ दिन पहले एल-मिल गया। पूर्व package.el , कई अन्य लोगों की तरह, मैं मैन्युअल रूप से ऐड-ऑन संभाल रहा था।

मैं वापस एल-पाने के लिए क्यों गया? मैं एक गिट रेपो (मेरा एक Github पैकेज जो MELPA में नहीं है) नहीं होने के बारे में कुछ पीपा अजीबता का सामना करना पड़ा , जबकि वह पैकेज वास्तव में गिट का उपयोग कर रहा है ... मैंने जांच करने या टिकट बनाने में परेशान नहीं किया, बस अपने पुराने को खींच लिया el-get config और मैं कुछ ही समय में जाने के लिए अच्छा था।

कुछ चीजें जो मुझे el-get के बारे में पसंद हैं :

• यह कई गाइटरों का समर्थन करता है, सिर्फ गिट नहीं।
• इसमें पर्याप्त पूर्व-परिभाषित व्यंजन शामिल हैं
• स्टार्टअप पर पीपा की तुलना में तेज़ ।
• और हां @lunaryorn, विकी कोड वितरित करने के लिए एक जगह नहीं है, फिर भी मैं गितुब रेपो नहीं बनाना चाहता अगर वहाँ एमास्मिररोर ( जीथब ) पर कोई क्लोन नहीं है ।
• आत्म निहित, पीपा के साथ आप एक बाहरी स्थापना की जरूरत है। मैं वर्गों के माध्यम से नेविगेट करने के लिए ऑलआउट-मोड के साथ एक इनिट फ़ाइल (मॉड्यूलर कॉन्फ़िगरेशन नहीं) का उपयोग करता हूं ।
• el-get यूजर के नजरिए से काफी सरल है।

नोट: मैं OSX और लिनक्स के तहत Emacs Git HEAD चला रहा हूं।

Comments

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

— चंद्रग्रहण

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

— चंद्र

मैं पीपा के संकीर्ण दायरे के बारे में सहमत हूं, मुझे गलत मत समझो। पीपा के साथ मेरी "परेशानियों" के बावजूद, मैं अभी भी कुछ लिनक्स मशीनों पर इसका उपयोग करता हूं। मेरे पास "गिट-ओनली" पैकेज भी नहीं हैं, उनमें से कुछ व्यापारिक या अन्य संस्करण नियंत्रण प्रणाली में हैं। मैं अन्य लोगों के पैकेजों का भी उपयोग करता हूं जो संभवतः एमईएलपीए या गिट रिपॉजिटरी में कभी नहीं होंगे। मेरा एकमात्र मुद्दा यह है कि जब एमईएलपीए में किसी के लिए आवश्यक सभी पैकेज नहीं होते हैं तब एल-गेट अभी भी ठीक है। जबकि मुझे QUELPA की जानकारी है, एल-गेट मेरे लिए काफी अच्छा है।

— रिमेरो

देखिए, और मेरा कहना यह है कि एल-गेट विशेष रूप से आजकल ठीक नहीं है, क्योंकि यह ईएलपीए और एमएसीएस के अंतर्निहित निर्भरता प्रबंधन, ब्रेकिंग और डुप्लिकेट पैकेज प्रतिष्ठानों को दरकिनार करता है। QUELPA एल-गेट के समान सुविधाएँ प्रदान करता है, लेकिन इसमें कोई दोष नहीं है। यह आजकल बेहतर है।

— चंद्रोदय

@ श्रीमो मुझे बिल्कुल वही अनुभव था। उसके ऊपर, मैंने अभी कुछ दिनों पहले क्वेलपा की कोशिश की थी, और इसे कम से कम अभी के लिए छोड़ना था। एल-गेट अभी भी अधिक लचीला, शक्तिशाली और समग्र रूप से तेज है, कम से कम मेरे उपयोग-मामले के लिए लगता है। मेरा मानना ​​है कि वे दो अलग-अलग दृष्टिकोणों को अपनाते हैं, इसलिए यह इस पर भी निर्भर हो सकता है कि उपयोगकर्ता किस प्रकार का Emacs है। एक या दूसरे के लिए प्रतिबद्ध होने से पहले, दोनों की कोशिश करना उचित होगा।

— gsl

Answer 4

आप पर एक नज़र रखना चाहते हो सकता है paradox। यह एक और पैकेज मैनेजर नहीं है, लेकिन इसके लिए एक नेचर फ्रंट एंड है package.el। उदाहरण के लिए, जब आप पैकेज अपडेट करते हैं, तो यह पूछता है कि क्या आप उन्हें इंस्टॉल करना चाहते हैं और पुराने को एक चरण में हटा सकते हैं।

आप इसका इस्तेमाल करते हैं, तो आप शायद सेट करना चाहते paradox-execute-asynchronouslyकरने के लिए tअपने init फाइल में।