हास्केल कबाल:

Question

मेरी cabal install एड संकुल के सभी बाहर साफ़ करने के बाद, मैं इस निम्नलिखित सत्र भाग गया "पैकेज परोक्ष रूप से एक ही पैकेज के कई संस्करण पर निर्भर करता है":

$ cabal update 
Downloading the latest package list from hackage.haskell.org 
james@bast:~/.cabal/packages$ cabal install cabal-dev 
Resolving dependencies... 
Downloading cabal-dev-0.9.1... 
[1 of 1] Compiling Main    (/tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/Setup.hs, /tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/dist/setup/Main.o) 
Linking /tmp/cabal-dev-0.9.124882/cabal-dev-0.9.1/dist/setup/setup ... 
Configuring cabal-dev-0.9.1... 
Warning: This package indirectly depends on multiple versions of the same 
package. This is highly likely to cause a compile failure. 
package containers-0.4.2.1 requires array-0.4.0.0 
package Cabal-1.14.0 requires array-0.4.0.0 
package text-0.11.1.13 requires array-0.4.0.0 
package deepseq-1.3.0.0 requires array-0.4.0.0 
package containers-0.4.2.1 requires array-0.4.0.0 
package HTTP-4000.2.2 requires array-0.4.0.0 
package cabal-dev-0.9.1 requires containers-0.4.2.1 
package Cabal-1.14.0 requires containers-0.4.2.1 
package template-haskell-2.7.0.0 requires containers-0.4.2.1 
Building cabal-dev-0.9.1... 
Preprocessing executable 'ghc-pkg-6_8-compat' for cabal-dev-0.9.1... 
<command line>: cannot satisfy -package-id Cabal-1.14.0-4af45d3c8d10dc27db38ae0e7e5a952b: 
    Cabal-1.14.0-4af45d3c8d10dc27db38ae0e7e5a952b is unusable due to missing or recursive dependencies: 
     array-0.4.0.0-46f61f5fd9543ebf309552ef84dccc86 containers-0.4.2.1-98f9aa15f9c08b13673dc9d89385f449 
    (use -v for more information) 
cabal: Error: some packages failed to install: 
cabal-dev-0.9.1 failed during the building phase. The exception was: 
ExitFailure 1 
$ 

तो कारण मैं cabal-dev स्थापित नहीं कर सकता स्पष्ट रूप से या तो

• यह "अप्रत्यक्ष रूप से उसी पैकेज के कई संस्करणों पर निर्भर करता है।" हालांकि, cabal उस पैकेज का नाम नहीं है जिसका दावा है कि cabal-dev के कई संस्करणों की आवश्यकता है।
• Cabal-1.14.0 में "गायब या पुनरावर्ती निर्भरता" है, विशेष रूप से array-0.4.0.0 और containers-0.4.2.1 शामिल है।

निर्भरता में सूचीबद्ध करता है का ग्राफ पुष्टि की है कि इन दावों में से कोई भी सत्य हैं (या निर्भरता इस सूची में झूठी या अधूरी हैं):

तो: मैं क्या याद आ रही है? कौन या क्या गलत है: मुझे, cabal, या एक या अधिक पैकेज?

मैं चला रहा हूँ:

$ cabal --version 
cabal-install version 0.10.2 
using version 1.10.1.0 of the Cabal library 
$ ghc --version 
The Glorious Glasgow Haskell Compilation System, version 7.4.1 
$ 

Answer 1

समस्या उत्पन्न होती है जब हम पैकेज बी है और सी पहले से ही स्थापित है, लेकिन विकास के विभिन्न संस्करणों के खिलाफ बनाया गया और फिर हम दोनों संकुल बी और सी पैकेज एक में एक साथ उपयोग करने का प्रयास : डायमंड निर्भरता समस्या यह ठीक काम कर सकती है, लेकिन केवल तभी जब पैकेज बी और सी उनके इंटरफेस में डी में परिभाषित प्रकारों का खुलासा नहीं करते हैं। यदि वे करते हैं तो पैकेज ए बी और सी से कार्यों का उपयोग करने में सक्षम नहीं होगा क्योंकि वे एक ही प्रकार के साथ काम नहीं करेंगे। यही आपको एक प्रकार की त्रुटि मिलेगी।

एक ठोस उदाहरण चुनने के लिए, मान लें कि पैकेज डी बाइटस्ट्रिंग है और हमारे पास दोनों bytestring-0.9.0.1 और 0.9.0.4 स्थापित हैं। मान लें कि बी utf8-string है और सी regex-base है। आइए कहें कि पैकेज ए यी संपादक प्रोग्राम है। तो मुद्दा यह है कि, यी में कोड में किसी स्थान पर हम यूटीएफ -8 डिकोडिंग के परिणामस्वरूप रेगेक्स फ़ंक्शंस में इनपुट के रूप में उत्पादित एक बाइटस्ट्रिंग पास करना चाहते हैं। लेकिन यह काम नहीं करता है क्योंकि utf8-string पैकेज में फ़ंक्शन बाइटस्ट्रिंग प्रकार का उपयोग bytestring-0.9.0.1 से कर रहे हैं जबकि रेगेक्स पैकेज में रेगेक्स फ़ंक्शन बाइटस्ट्रिंग प्रकार का उपयोग bytestring-0.9.0.4 से कर रहे हैं। तो हम एक प्रकार त्रुटि मिलती है जब हम यी संकलन करने का प्रयास करें:

मैच अपेक्षित प्रकार bytestring-0.9.0.4:Data.ByteString.ByteString' against inferred type bytestring-0.9.0.1 नहीं कर सका: Data.ByteString.ByteString '

जहां तक ​​GHC जानता है, इन दो प्रकार के होते हैं पूरी तरह से असंबंधित!

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

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

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

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

नाटक की वर्तमान स्थिति यह है कि कैबल इस समस्या की चेतावनी देता है लेकिन वास्तव में इसे हल करने में आपकी सहायता नहीं करता है। उपरोक्त उदाहरण के लिए हम प्राप्त करेंगे:

$ cabal configure 
Configuring A-1.0... 
Warning: This package indirectly depends on multiple versions of 
the same package. This is highly likely to cause a compile failure. 
package B-1.0 requires D-1.0 
package C-1.0 requires D-1.1