Julia 1.0

Pkg




julia

Pkg

परिचय

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

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

Pkg का स्थानीय वातावरण के प्रति दृष्टिकोण उन लोगों से परिचित हो सकता है जिन्होंने Python के virtualenv या Ruby के bundler । जूलिया में, पर्यावरण का समर्थन करने के लिए भाषा के कोड लोडिंग तंत्र को हैक करने के बजाय, हमारे पास यह लाभ है कि जूलिया मूल रूप से उन्हें समझता है। इसके अलावा, जूलिया वातावरण "स्टैकेबल" हैं: आप एक पर्यावरण को दूसरे के साथ ओवरले कर सकते हैं और जिससे प्राथमिक वातावरण के बाहर अतिरिक्त पैकेज तक पहुंच हो सकती है। यह एक परियोजना पर काम करना आसान बनाता है, जो प्राथमिक वातावरण प्रदान करता है, जबकि अभी भी आपके सभी सामान्य उपकरण जैसे कि प्रोफाइलर, डीबगर्स, और इसी तरह, इन पथों में बाद में लोड पथ में एक पर्यावरण होने के साथ-साथ इन सभी उपकरणों तक पहुंच है।

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

शब्दकोष

प्रोजेक्ट: जूलिया कोड के मुख्य निकाय के लिए एक src डायरेक्टरी सहित एक मानक लेआउट के साथ एक सोर्स ट्री, प्रोजेक्ट के परीक्षण के लिए एक test निर्देशिका, डॉक्यूमेंटेशन फ़ाइलों के लिए docs , और वैकल्पिक रूप से एक बिल्ड स्क्रिप्ट और उसके आउटपुट के लिए एक deps डायरेक्टरी। एक परियोजना में आम तौर पर एक परियोजना फ़ाइल होगी और वैकल्पिक रूप से एक प्रकट फ़ाइल हो सकती है:

  • प्रोजेक्ट फ़ाइल: किसी प्रोजेक्ट की रूट डायरेक्टरी में एक फ़ाइल, जिसका नाम Project.toml (या JuliaProject.toml ) है, जो प्रोजेक्ट के बारे में मेटाडेटा का वर्णन करती है, जिसमें उसका नाम, UUID (पैकेज के लिए), लेखक, लाइसेंस और पैकेज के नाम और UUID शामिल हैं और पुस्तकालयों कि यह पर निर्भर करता है।

  • मैनिफेस्ट फ़ाइल: किसी प्रोजेक्ट की रूट डायरेक्टरी में एक फाइल, जिसका नाम Manifest.toml (या JuliaManifest.toml ) है, जो एक प्रोजेक्ट द्वारा उपयोग किए जाने वाले प्रत्येक पैकेज और लाइब्रेरी के पूर्ण निर्भरता ग्राफ और सटीक संस्करणों का वर्णन करता है।

पैकेज: एक परियोजना जो पुन: प्रयोज्य कार्यक्षमता प्रदान करती है जिसका उपयोग अन्य जूलिया परियोजनाओं द्वारा import X या using X किया जा सकता है। एक पैकेज में एक परियोजना फ़ाइल होनी चाहिए जिसमें एक uuid प्रविष्टि हो, जो अपने पैकेज को UUID दे। इस यूयूआईडी का उपयोग उन परियोजनाओं में पैकेज की पहचान करने के लिए किया जाता है जो इस पर निर्भर करते हैं।

ध्यान दें

विरासत के कारणों के लिए यह एक परियोजना फ़ाइल या REPL से UUID या एक स्क्रिप्ट के शीर्ष स्तर के बिना एक पैकेज लोड करने के लिए संभव है। हालांकि, यह संभव नहीं है कि एक परियोजना फ़ाइल या UUID के बिना एक पैकेज को लोड करने के लिए उनके साथ एक परियोजना से। एक बार जब आप एक परियोजना फ़ाइल से लोड हो जाते हैं, तो सब कुछ एक परियोजना फ़ाइल और UUID की आवश्यकता होती है।

अनुप्रयोग: एक परियोजना जो स्टैंडअलोन कार्यक्षमता प्रदान करती है जिसका उद्देश्य अन्य जूलिया परियोजनाओं द्वारा पुन: उपयोग नहीं किया जाना है। उदाहरण के लिए एक वेब एप्लिकेशन या एक कमांड-लाइन उपयोगिता, या एक वैज्ञानिक पेपर के साथ सिमुलेशन / एनालिटिक्स कोड। एक आवेदन में एक UUID हो सकता है लेकिन उसे एक की आवश्यकता नहीं है। एक आवेदन भी इस पर निर्भर करता है संकुल के लिए वैश्विक विन्यास विकल्प प्रदान कर सकता है। दूसरी ओर, पैकेज वैश्विक कॉन्फ़िगरेशन प्रदान नहीं कर सकते हैं क्योंकि यह मुख्य एप्लिकेशन के कॉन्फ़िगरेशन के साथ संघर्ष कर सकता है।

ध्यान दें

परियोजना बनाम पैकेज बनाम आवेदन:

  1. प्रोजेक्ट एक छत्र शब्द है: पैकेज और एप्लिकेशन प्रोजेक्ट के प्रकार हैं।
  2. पैकेज में UUIDs होना चाहिए, अनुप्रयोगों में UUID हो सकते हैं लेकिन उनकी आवश्यकता नहीं है।
  3. अनुप्रयोग वैश्विक कॉन्फ़िगरेशन प्रदान कर सकते हैं, जबकि पैकेज नहीं कर सकते।

पुस्तकालय (भविष्य का काम): एक संकलित बाइनरी निर्भरता (जूलिया में नहीं लिखा गया) जिसे जूलिया परियोजना द्वारा उपयोग किया जाना है। ये वर्तमान में एक प्रोजेक्ट के सोर्स ट्री में deps/build.jl स्क्रिप्ट द्वारा इन-प्लेस बनाया गया है, लेकिन भविष्य में हम पैकेज मैनेजर द्वारा पुस्तकालयों को सीधे प्रथम श्रेणी की deps/build.jl बनाने और अपग्रेड करने की योजना बना रहे हैं।

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

  • स्पष्ट वातावरण: एक स्पष्ट प्रोजेक्ट फ़ाइल के रूप में एक वातावरण और एक निर्देशिका में एक वैकल्पिक संबंधित मैनिफ़ेस्ट फ़ाइल। यदि मैनिफ़ेस्ट फ़ाइल अनुपस्थित है, तो निहित निर्भरता ग्राफ़ और स्थान मैप रिक्त हैं।

  • निहित पर्यावरण: एक वातावरण (एक परियोजना फ़ाइल या प्रकट फ़ाइल के बिना) एक फार्म के रूप में प्रदान किया जाता है जिसमें फॉर्म X.jl , X.jl/src/X.jl या X/src/X.jl प्रवेश बिंदु X/src/X.jl । शीर्ष स्तर के नाम का नक्शा इन प्रवेश बिंदुओं द्वारा निहित है। निर्भरता ग्राफ इन पैकेज निर्देशिकाओं, जैसे X.jl/Project.toml या X/Project.toml अंदर प्रोजेक्ट फ़ाइलों के अस्तित्व से निहित है। X पैकेज की निर्भरताएँ यदि एक हैं तो संबंधित प्रोजेक्ट फ़ाइल में निर्भरताएँ हैं। स्थान का नक्शा प्रवेश बिंदुओं द्वारा स्वयं निहित है।

रजिस्ट्री: पैकेज के एक पंजीकृत सेट के बारे में एक मानक लेआउट रिकॉर्डिंग मेटाडेटा के साथ एक स्रोत का पेड़, उनमें से टैग किए गए संस्करण जो उपलब्ध हैं, और जो संकुल के संस्करण एक दूसरे के साथ संगत या असंगत हैं। एक रजिस्ट्री को पैकेज के नाम और UUID द्वारा अनुक्रमित किया जाता है, और इसके बारे में निम्नलिखित मेटाडेटा प्रदान करने वाले प्रत्येक पंजीकृत पैकेज के लिए एक निर्देशिका है:

  • नाम - जैसे DataFrames
  • UUID - जैसे a93c6f00-e57d-5684-b7b6-d8193f3e46c0
  • लेखक - जैसे Jane Q. Developer <[email protected]>
  • लाइसेंस - जैसे MIT, BSD3, या GPLv2
  • रिपॉजिटरी - उदाहरण https://github.com/JuliaData/DataFrames.jl.git
  • विवरण - एक पैकेज की कार्यक्षमता का सार पाठ का एक ब्लॉक
  • कीवर्ड - उदाहरण के लिए data , tabular , analysis , statistics
  • संस्करण - सभी पंजीकृत संस्करण टैग की एक सूची

पैकेज के प्रत्येक पंजीकृत संस्करण के लिए, निम्नलिखित जानकारी प्रदान की गई है:

  • इसका शब्दार्थ संस्करण संख्या - उदाहरण के लिए v1.2.3
  • इसके गिट पेड़ SHA-1 हैश - जैसे 7ffb18ea3245ef98e368b02b81e8a86543a11103
  • निर्भरता के UUIDs के नाम से एक नक्शा
  • अन्य संकुल के कौन से संस्करण संगत / असंगत हैं

निर्भरताएं और संगतता पैकेज संस्करणों की श्रेणियों का उपयोग करके एक संकुचित लेकिन मानव-पठनीय प्रारूप में संग्रहीत की जाती हैं।

डिपो: एक निर्देशिका जिस सिस्टम पर विभिन्न पैकेज-संबंधित संसाधन रहते हैं, जिसमें शामिल हैं:

  • environments : साझा नाम वातावरण (उदाहरण के लिए v1.0 , devtools )
  • clones : पैकेज रिपॉजिटरी के नंगे क्लोन
  • compiled : संकलित संकुल चित्र ( .ji फ़ाइलें)
  • config : वैश्विक कॉन्फ़िगरेशन फ़ाइलें (उदा। startup.jl )
  • dev : पैकेज विकास के लिए डिफ़ॉल्ट निर्देशिका
  • logs : लॉग फाइलें (जैसे manifest_usage.tomlrepl_history.jl , repl_history.jl )
  • packages : स्थापित पैकेज संस्करण
  • registries : registries क्लोन (जैसे General )

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

डिपो पथ: डिपो स्थानों का एक ढेर जहां पैकेज प्रबंधक, साथ ही जूलिया के कोड लोडिंग तंत्र, रजिस्ट्रियों, स्थापित पैकेज, नामित वातावरण, रेपो क्लोन, कैश्ड संकलित पैकेज छवियों और कॉन्फ़िगरेशन फ़ाइलों की तलाश करें। डिपो पथ जूलिया DEPOT_PATH वैश्विक चर द्वारा नियंत्रित किया जाता है, जो कि JULIA_DEPOT_PATH पर्यावरण चर के मूल्य के आधार पर स्टार्टअप पर आबाद है। पहली प्रविष्टि "उपयोगकर्ता डिपो" है और वर्तमान उपयोगकर्ता द्वारा स्वामित्व और स्वामित्व वाली होनी चाहिए। उपयोगकर्ता डिपो वह जगह है: रजिस्ट्रियों को क्लोन किया जाता है, नए पैकेज संस्करण स्थापित किए जाते हैं, नामांकित वातावरण बनाए जाते हैं और अद्यतन किए जाते हैं, पैकेज रिपोज क्लोन किए जाते हैं, नए संकलित पैकेज छवि फ़ाइलों को सहेजा जाता है, लॉग फाइलें लिखी जाती हैं, विकास पैकेज डिफ़ॉल्ट रूप से जांचे जाते हैं, और वैश्विक कॉन्फ़िगरेशन डेटा सहेजा गया है। डिपो पथ में बाद की प्रविष्टियों को केवल-पढ़ने के रूप में माना जाता है और सिस्टम प्रशासकों द्वारा स्थापित और प्रबंधित रजिस्ट्रियों, पैकेजों आदि के लिए उपयुक्त हैं।

शुरू करना

Pkg REPL- मोड जूलिया REPL से दर्ज किया गया है कुंजी का उपयोग ]

(v1.0) pkg>

प्रॉम्प्ट के कोष्ठक के अंदर का हिस्सा वर्तमान परियोजना का नाम दिखाता है। चूंकि हमने अपना प्रोजेक्ट अभी तक नहीं बनाया है, इसलिए हम डिफ़ॉल्ट प्रोजेक्ट में हैं, ~/.julia/environments/v1.0 पर स्थित (या जूलिया का जो भी संस्करण आप चलाने के लिए होता है)।

julia> प्रॉम्प्ट पर लौटने के लिए, इनपुट लाइन खाली होने पर या तो बैकस्पेस दबाएं या Ctrl + C दबाएं। सहायता pkg> help को कॉल करके उपलब्ध है। यदि आप एक ऐसे वातावरण में हैं, जिसकी एक REPL तक पहुंच नहीं है, तो आप using Pkg बाद उपलब्ध स्ट्रिंग मैक्रो using Pkg करके REPL मोड कमांड का using Pkg । आदेश pkg"cmd" REPL मोड में cmd निष्पादित करने के बराबर होगा।

प्रलेखन यहाँ REPL मोड से Pkg का उपयोग करने का वर्णन करता है। Pkg API ( Pkg. फ़ंक्शन को कॉल करके) का उपयोग करने का प्रलेखन लिखित होने की प्रगति पर है।

पैकेज जोड़ना

पैकेज जोड़ने के दो तरीके हैं, या तो add कमांड या dev कमांड का उपयोग करें। सबसे अधिक इस्तेमाल किया जाने वाला एक add और इसका उपयोग पहले वर्णित है।

पंजीकृत पैकेज जोड़ना

Pkg REPL में पैकेज को कमांड के साथ जोड़ा जा सकता है, जिसके बाद पैकेज का नाम आता है, उदाहरण के लिए:

(v1.0) pkg> add Example
   Cloning default registries into /Users/kristoffer/.julia/registries
   Cloning registry General from "https://github.com/JuliaRegistries/General.git"
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] + Example v0.5.1
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] + Example v0.5.1
  [8dfed614] + Test

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

(v1.0) pkg> st
    Status `Project.toml`
  [7876af07] Example v0.5.1

प्रकट स्थिति, इसके अलावा, स्पष्ट रूप से जोड़े गए पैकेजों की निर्भरता शामिल है।

(v1.0) pkg> st --manifest
    Status `Manifest.toml`
  [7876af07] Example v0.5.1
  [8dfed614] Test

pkg> add ABC रूप में एक कमांड में कई पैकेज जोड़ना संभव है।

पैकेज को प्रोजेक्ट में जोड़े जाने के बाद, इसे जूलिया में लोड किया जा सकता है:

julia> using Example

julia> Example.hello("User")
"Hello, User"

पैकेज के नाम पर @ प्रतीक, जैसे @v0.4 , के बाद एक संस्करण जोड़कर एक विशिष्ट संस्करण स्थापित किया जा सकता है:

(v1.0) pkg> add [email protected]
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] + Example v0.4.1
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] + Example v0.4.1

यदि Example की मास्टर शाखा (या एक निश्चित प्रतिबद्ध SHA) में एक हॉटफ़िक्स है जो अभी तक एक पंजीकृत संस्करण में शामिल नहीं है, तो हम पैकेज नाम में #branch (या #commit ) को जोड़कर एक शाखा (या प्रतिबद्ध) को स्पष्ट रूप से ट्रैक कर सकते हैं:

(v1.0) pkg> add Example#master
  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git)
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git)

स्टेटस आउटपुट अब दिखाता है कि हम Example के master ब्रांच को ट्रैक कर रहे हैं। संकुल अद्यतन करते समय, हम उस शाखा से अद्यतन खींचेंगे।

Example के रजिस्ट्री संस्करण को ट्रैक करने के लिए वापस जाने के लिए, कमांड free का उपयोग किया जाता है:

(v1.0) pkg> free Example
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] ~ Example v0.5.1+ #master (https://github.com/JuliaLang/Example.jl.git) ⇒ v0.5.1
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] ~ Example v0.5.1+ #master )https://github.com/JuliaLang/Example.jl.git) ⇒ v0.5.1

अपंजीकृत पैकेज जोड़ना

यदि कोई पैकेज रजिस्ट्री में नहीं है, तो उसे add लिए रिपॉजिटरी को URL देने वाले पैकेज नाम के बजाय इसे अभी भी जोड़ा जा सकता है।

(v1.0) pkg> add https://github.com/fredrikekre/ImportMacros.jl
  Updating git-repo `https://github.com/fredrikekre/ImportMacros.jl`
 Resolving package versions...
Downloaded MacroTools ─ v0.4.1
  Updating `~/.julia/environments/v1.0/Project.toml`
  [e6797606] + ImportMacros v0.0.0 # (https://github.com/fredrikekre/ImportMacros.jl)
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [e6797606] + ImportMacros v0.0.0 # (https://github.com/fredrikekre/ImportMacros.jl)
  [1914dd2f] + MacroTools v0.4.1

अपंजीकृत पैकेज (यहां MacroTools ) की निर्भरता स्थापित हो गई। अपंजीकृत पैकेजों के लिए, हम पंजीकृत पैकेजों की तरह # का उपयोग करने के लिए एक शाखा (या प्रतिबद्ध SHA) दे सकते थे।

एक स्थानीय पैकेज जोड़ना

इसके बजाय हम add लिए git रेपो का URL देने के बजाय git रेपो को एक स्थानीय रास्ता दे सकते हैं। यह URL जोड़ने के समान ही काम करता है। स्थानीय रिपॉजिटरी को (कुछ शाखा में) ट्रैक किया जाएगा और पैकेज अपडेट होने पर उस स्थानीय रेपो से अपडेट खींचा जाएगा। ध्यान दें कि उस पैकेज को लोड करते समय स्थानीय पैकेज रिपॉजिटरी में फाइलों में परिवर्तन तुरंत दिखाई नहीं देगा। परिवर्तनों के लिए प्रतिबद्ध होना चाहिए और बदलावों में खींचने के लिए पैकेज अद्यतन किए गए।

संकुल का विकास करना

केवल add घटाव का उपयोग करने से आपके मेनिफेस्ट में हमेशा एक "प्रतिलिपि प्रस्तुत करने योग्य राज्य" होगा, दूसरे शब्दों में, जब तक उपयोग किए जाने वाले रिपॉजिटरी और रजिस्ट्रियां अभी भी सुलभ हैं, परियोजना में सभी निर्भरताओं की सटीक स्थिति को पुनर्प्राप्त करना संभव है। इसका यह फायदा है कि आप अपनी परियोजना ( Project.toml और Manifest.toml ) किसी और को भेज सकते हैं और वे उस परियोजना को उसी स्थिति में "इंस्टेंट" कर सकते हैं, जैसा कि आपके पास स्थानीय स्तर पर था। हालाँकि, जब आप एक पैकेज विकसित कर रहे होते हैं, तो कुछ पथ पर उनकी वर्तमान स्थिति में पैकेज लोड करना अधिक सुविधाजनक होता है। इस कारण से, dev कमांड मौजूद है।

आइए एक पंजीकृत पैकेज को dev करने का प्रयास करें:

(v1.0) pkg> dev Example
  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] + Example v0.5.1+ [`~/.julia/dev/Example`]
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] + Example v0.5.1+ [`~/.julia/dev/Example`]

dev कमांड ~/.julia/dev/ (पर्यावरण चर JULIA_PKG_DEVDIR सेट करके पथ को बदला जा सकता है) पैकेज का पूरा क्लोन प्राप्त करता है। Example आयात करते समय जूलिया अब इसे ~/.julia/dev/Example से आयात करेगी और उस पथ में फ़ाइलों में जो भी स्थानीय परिवर्तन किए गए हैं, वे परिणामस्वरूप लोड किए गए कोड में परिलक्षित होते हैं। जब हमने add उपयोग किया तो हमने कहा कि हमने पैकेज रिपॉजिटरी को ट्रैक किया है, हम यहां कहते हैं कि हम खुद ही ट्रैक ट्रैक करते हैं। ध्यान दें कि पैकेज मैनेजर ट्रैक की गई किसी भी फाइल को कभी भी टच नहीं करेगा। इसलिए यह आपके ऊपर है कि आप अपडेट्स, ब्रांचेज आदि को बदलें। अगर हम किसी ब्रांच में एक पैकेज को ~/.julia/dev/ करने की कोशिश करते हैं जो पहले से ही मौजूद है। ~/.julia/dev/ पैकेज मैनेजर तो हम मौजूदा रास्ते का इस्तेमाल करेंगे। उदाहरण के लिए:

(v1.0) pkg> dev Example
  Updating git-repo `https://github.com/JuliaLang/Example.jl.git`
[ Info: Path `/Users/kristoffer/.julia/dev/Example` exists and looks like the correct package, using existing path instead of cloning

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

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

एक पथ को ट्रैक करने से रोकने के लिए और पंजीकृत संस्करण का फिर से उपयोग free , free उपयोग free

(v1.0) pkg> free Example
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] ↓ Example v0.5.1+ [`~/.julia/dev/Example`] ⇒ v0.5.1
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] ↓ Example v0.5.1+ [`~/.julia/dev/Example`] ⇒ v0.5.1

यह ध्यान दिया जाना चाहिए कि dev द्वारा आपकी परियोजना अब स्वाभाविक रूप से राज्य है। इसका राज्य पथ पर मौजूद फ़ाइलों की वर्तमान सामग्री पर निर्भर करता है और किसी पथ पर नज़र रखने वाले सभी पैकेजों की सटीक सामग्री को जाने बिना किसी और द्वारा "त्वरित" नहीं किया जा सकता है।

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

संकुल हटाना

संकुल को मौजूदा परियोजना से pkg> rm Package उपयोग से हटाया जा सकता है। यह केवल प्रोजेक्ट में मौजूद पैकेजों को हटाएगा, एक पैकेज को हटाने के लिए जो केवल एक निर्भरता उपयोग के रूप में मौजूद है pkg> rm --manifest DepPackage । ध्यान दें कि यह सभी पैकेजों को हटा देगा जो DepPackage पर निर्भर करता है।

संकुल अद्यतन कर रहा है

जब पैकेज के नए संस्करण प्रोजेक्ट का उपयोग कर रहे हैं, तो जारी किया जाता है, यह अद्यतन करने के लिए एक अच्छा विचार है। बस कॉल up से प्रोजेक्ट की सभी निर्भरता को नवीनतम संगत संस्करण में अपडेट करने का प्रयास किया जाएगा। कभी-कभी यह वह नहीं होता है जो आप चाहते हैं। आप उन्हें up करने के लिए तर्क के रूप में अपग्रेड करने के लिए निर्भरता का एक सबसेट निर्दिष्ट कर सकते हैं, उदाहरण के लिए:

(v1.0) pkg> up Example

अन्य सभी संकुल प्रत्यक्ष निर्भरता का संस्करण समान रहेगा। यदि आप केवल अपनी परियोजना के जोखिम को कम करने के लिए, पैकेज के मामूली संस्करण को अपडेट करना चाहते हैं, तो आप --minor फ्लैग दे सकते हैं, जैसे:

(v1.0) pkg> up --minor Example

एक मामूली अपग्रेड किए जाने पर रिपॉजिटरी को ट्रैक करने वाले पैकेज अपडेट नहीं होते हैं। पैकेज को ट्रैक करने वाले पैकेज को पैकेज मैनेजर द्वारा कभी नहीं छुआ जाता है।

एक पैकेज पिनिंग

एक पिन किए गए पैकेज को कभी भी अपडेट नहीं किया जाएगा। उदाहरण के लिए pin का उपयोग करके एक पैकेज pin किया जा सकता है

(v1.0) pkg> pin Example
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1 ⚲
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] ~ Example v0.5.1 ⇒ v0.5.1 ⚲

पिन प्रतीक पर ध्यान दें दिखा रहा है कि पैकेज पिन किया गया है। पिन को हटाकर free का उपयोग किया जाता है

(v1.0) pkg> free Example
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7876af07] ~ Example v0.5.1 ⚲ ⇒ v0.5.1
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7876af07] ~ Example v0.5.1 ⚲ ⇒ v0.5.1

परीक्षण पैकेज

पैकेज के लिए test कमांड का उपयोग करके चलाया जा सकता है:

(v1.0) pkg> test Example
   Testing Example
   Testing Example tests passed

बिल्डिंग पैकेज

एक पैकेज का निर्माण कदम स्वचालित रूप से चलाया जाता है जब एक पैकेज पहली बार स्थापित होता है। निर्माण प्रक्रिया का आउटपुट एक फ़ाइल को निर्देशित किया जाता है। पैकेज के लिए बिल्ड स्टेप को स्पष्ट रूप से चलाने के लिए build कमांड का उपयोग किया जाता है:

(v1.0) pkg> build MbedTLS
  Building MbedTLS → `~/.julia/packages/MbedTLS/h1Vu/deps/build.log`

shell> cat ~/.julia/packages/MbedTLS/h1Vu/deps/build.log
┌ Warning: `wait(t::Task)` is deprecated, use `fetch(t)` instead.
│   caller = macro expansion at OutputCollector.jl:63 [inlined]
â”” @ Core OutputCollector.jl:63
...
[ Info: using prebuilt binaries

अपने खुद के प्रोजेक्ट बनाना

अभी तक हमने ~/.julia/environments/v1.0 पर डिफ़ॉल्ट प्रोजेक्ट में पैकेज जोड़े हैं, हालांकि, अन्य, स्वतंत्र, प्रोजेक्ट बनाना आसान है। यह इंगित किया जाना चाहिए कि यदि दो परियोजनाएं एक ही संस्करण में एक ही पैकेज का उपयोग करती हैं, तो इस पैकेज की सामग्री को डुप्लिकेट नहीं किया गया है। एक नई परियोजना बनाने के लिए, इसके लिए एक निर्देशिका बनाएं और फिर उस निर्देशिका को "सक्रिय परियोजना" बनाने के लिए सक्रिय करें जो पैकेज संचालन में हेरफेर करती है:

shell> mkdir MyProject

shell> cd MyProject
/Users/kristoffer/MyProject

(v1.0) pkg> activate .

(MyProject) pkg> st
    Status `Project.toml`

ध्यान दें कि जब नया प्रोजेक्ट सक्रिय होता है तो REPL प्रॉम्प्ट बदल जाता है। चूंकि यह एक नई बनाई गई परियोजना है, स्थिति कमांड दिखाती है कि इसमें कोई पैकेज नहीं है, और वास्तव में, इसमें कोई परियोजना या प्रकट फ़ाइल नहीं है जब तक हम इसमें पैकेज नहीं जोड़ते हैं:

shell> ls -l
total 0

(MyProject) pkg> add Example
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `Project.toml`
  [7876af07] + Example v0.5.1
  Updating `Manifest.toml`
  [7876af07] + Example v0.5.1
  [8dfed614] + Test

shell> ls -l
total 8
-rw-r--r-- 1 stefan staff 207 Jul  3 16:35 Manifest.toml
-rw-r--r-- 1 stefan staff  56 Jul  3 16:35 Project.toml

shell> cat Project.toml
[deps]
Example = "7876af07-990d-54b4-ab0e-23690620f79a"

shell> cat Manifest.toml
[[Example]]
deps = ["Test"]
git-tree-sha1 = "8eb7b4d4ca487caade9ba3e85932e28ce6d6e1f8"
uuid = "7876af07-990d-54b4-ab0e-23690620f79a"
version = "0.5.1"

[[Test]]
uuid = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

यह नया वातावरण पहले के उपयोग से पूरी तरह से अलग है।

कचरा संग्रहित पुराना, अप्रयुक्त पैकेज

जैसे ही पैकेज अपडेट किए जाते हैं और परियोजनाएं हटा दी जाती हैं, स्थापित पैकेज जो एक बार उपयोग किए गए थे वे अनिवार्य रूप से पुराने हो जाएंगे और किसी भी मौजूदा परियोजना से उपयोग नहीं किए जाएंगे। Pkg उपयोग की जाने वाली सभी परियोजनाओं का एक लॉग रखता है, इसलिए यह लॉग के माध्यम से जा सकता है और यह देख सकता है कि कौन सी परियोजनाएं अभी भी मौजूद हैं और उन परियोजनाओं का क्या पैकेज है। बाकी को हटाया जा सकता है। यह gc कमांड के साथ किया जाता है:

(v1.0) pkg> gc
    Active manifests at:
        `/Users/kristoffer/BinaryProvider/Manifest.toml`
        ...
        `/Users/kristoffer/Compat.jl/Manifest.toml`
   Deleted /Users/kristoffer/.julia/packages/BenchmarkTools/1cAj: 146.302 KiB
   Deleted /Users/kristoffer/.julia/packages/Cassette/BXVB: 795.557 KiB
   ...
   Deleted /Users/kristoffer/.julia/packages/WeakRefStrings/YrK6: 27.328 KiB
   Deleted 36 package installations: 113.205 MiB

ध्यान दें कि केवल ~/.julia/packages में ~/.julia/packages हटाए जाते हैं।

अपने खुद के पैकेज बनाना

एक पैकेज Project.toml फ़ाइल src/PackageName.jl फ़ाइल में एक name , uuid और version प्रविष्टि के साथ एक परियोजना है जो मॉड्यूल PackageName को परिभाषित करता है। पैकेज लोड होने पर इस फ़ाइल को निष्पादित किया जाता है।

एक पैकेज के लिए फाइल बनाना

एक नए पैकेज के लिए फाइल तैयार करने के लिए, pkg> generate उपयोग करें।

(v1.0) pkg> generate HelloWorld

यह निम्न फ़ाइलों के साथ एक नया प्रोजेक्ट HelloWorld बनाता है (बाहरी tree कमांड के साथ कल्पना की गई ):

shell> cd HelloWorld

shell> tree .
.
├── Project.toml
└── src
    └── HelloWorld.jl

1 directory, 2 files

Project.toml फ़ाइल में पैकेज का नाम, उसका विशिष्ट UUID, उसका संस्करण, लेखक और अंतिम निर्भरताएँ शामिल हैं:

name = "HelloWorld"
uuid = "b4cd1eb8-1e24-11e8-3319-93036a3eb9f3"
version = "0.1.0"
author = ["Some One <[email protected]>"]

[deps]

src/HelloWorld.jl की सामग्री है:

module HelloWorld

greet() = print("Hello World!")

end # module

अब हम प्रोजेक्ट को सक्रिय कर सकते हैं और पैकेज लोड कर सकते हैं:

pkg> activate .

julia> import HelloWorld

julia> HelloWorld.greet()
Hello World!

परियोजना के लिए निर्भरता जोड़ना

मान लें कि हम अपनी परियोजना में मानक पुस्तकालय पैकेज Random और पंजीकृत पैकेज JSON का उपयोग करना चाहते हैं। हम केवल इन पैकेजों को add हैं (ध्यान दें कि अब प्रॉम्प्ट नई उत्पन्न परियोजना का नाम कैसे दिखाता है, क्योंकि हम HelloWorld प्रोजेक्ट डायरेक्टरी के अंदर हैं):

(HelloWorld) pkg> add Random JSON
 Resolving package versions...
  Updating "~/Documents/HelloWorld/Project.toml"
 [682c06a0] + JSON v0.17.1
 [9a3f8284] + Random
  Updating "~/Documents/HelloWorld/Manifest.toml"
 [34da2185] + Compat v0.57.0
 [682c06a0] + JSON v0.17.1
 [4d1e1d77] + Nullables v0.0.4
 ...

Random और JSON दोनों को प्रोजेक्ट के Project.toml फ़ाइल में जोड़ा गया, और परिणामी निर्भरताएँ Manifest.toml फ़ाइल में जोड़ी गईं। रिज़ॉल्वर ने प्रत्येक पैकेज को उच्चतम संभव संस्करण के साथ स्थापित किया है, जबकि अभी भी संगतता का सम्मान करते हुए कि प्रत्येक पैकेज अपनी निर्भरता पर लागू होता है।

अब हम अपने प्रोजेक्ट में Random और JSON दोनों का उपयोग कर सकते हैं। src/HelloWorld.jl को बदलना

module HelloWorld

import Random
import JSON

greet() = print("Hello World!")
greet_alien() = print("Hello ", Random.randstring(8))

end # module

और पैकेज को पुनः लोड करते हुए, Random का उपयोग करने वाला नया greet_alien फ़ंक्शन का उपयोग किया जा सकता है:

julia> HelloWorld.greet_alien()
Hello aT157rHV

पैकेज में बिल्ड स्टेप जोड़ना।

पहली बार पैकेज स्थापित होने पर या build साथ स्पष्ट रूप से आह्वान किए जाने पर बिल्ड स्टेप को निष्पादित किया जाता है। फ़ाइल deps/build.jl निष्पादित करके एक पैकेज बनाया गया है।

shell> cat deps/build.log
I am being built...

(HelloWorld) pkg> build
  Building HelloWorld → `deps/build.log`
 Resolving package versions...

shell> cat deps/build.log
I am being built...

यदि बिल्ड चरण विफल हो जाता है, तो बिल्ड चरण का आउटपुट कंसोल पर मुद्रित होता है

shell> cat deps/build.jl
error("Ooops")

(HelloWorld) pkg> build
  Building HelloWorld → `deps/build.log`
 Resolving package versions...
┌ Error: Error building `HelloWorld`:
│ ERROR: LoadError: Ooops
│ Stacktrace:
│  [1] error(::String) at ./error.jl:33
│  [2] top-level scope at none:0
│  [3] include at ./boot.jl:317 [inlined]
│  [4] include_relative(::Module, ::String) at ./loading.jl:1071
│  [5] include(::Module, ::String) at ./sysimg.jl:29
│  [6] include(::String) at ./client.jl:393
│  [7] top-level scope at none:0
│ in expression starting at /Users/kristoffer/.julia/dev/Pkg/HelloWorld/deps/build.jl:1
â”” @ Pkg.Operations Operations.jl:938

पैकेज में परीक्षण जोड़ना

जब पैकेज का परीक्षण किया जाता है तो फ़ाइल test/runtests.jl निष्पादित किया जाता है।

shell> cat test/runtests.jl
println("Testing...")
(HelloWorld) pkg> test
   Testing HelloWorld
 Resolving package versions...
Testing...
   Testing HelloWorld tests passed

परीक्षण-विशिष्ट निर्भरताएँ

कभी-कभी कोई केवल परीक्षण के समय कुछ पैकेजों का उपयोग करना चाहता है, लेकिन पैकेज का उपयोग करने पर उन पर निर्भरता लागू नहीं करता है। यह [extras] निर्भरता और प्रोजेक्ट फ़ाइल में [targets] में एक test लक्ष्य को जोड़कर संभव है। यहाँ हम Test मानक पुस्तकालय को प्रोजेक्ट फ़ाइल में निम्नलिखित जोड़कर केवल परीक्षण निर्भरता के रूप में जोड़ते हैं:

[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["Test"]

अब हम Test स्क्रिप्ट में Test का उपयोग कर सकते हैं और हम देख सकते हैं कि यह परीक्षण पर स्थापित हो गया है:

shell> cat test/runtests.jl
using Test
@test 1 == 1

(HelloWorld) pkg> test
   Testing HelloWorld
 Resolving package versions...
  Updating `/var/folders/64/76tk_g152sg6c6t0b4nkn1vw0000gn/T/tmpPzUPPw/Project.toml`
  [d8327f2a] + HelloWorld v0.1.0 [`~/.julia/dev/Pkg/HelloWorld`]
  [8dfed614] + Test
  Updating `/var/folders/64/76tk_g152sg6c6t0b4nkn1vw0000gn/T/tmpPzUPPw/Manifest.toml`
  [d8327f2a] + HelloWorld v0.1.0 [`~/.julia/dev/Pkg/HelloWorld`]
   Testing HelloWorld tests passed```

अनुकूलता

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

उदाहरण के लिए Project.toml फ़ाइल में निर्भरता के लिए संगतता दर्ज की गई है:

[compat]
julia = "1.0"
Example = "0.4.3"

संगतता प्रविष्टि को प्रोजेक्ट फ़ाइल में डालने के बाद, इसे लागू करने के लिए उपयोग किया जा सकता है।

संस्करण विनिर्देशक का प्रारूप नीचे विस्तार से वर्णित है।

जानकारी

वर्तमान में Pkg REPL मोड से अनुकूलता देने का कोई तरीका नहीं है, इसलिए अब किसी को प्रोजेक्ट फ़ाइल को मैन्युअल रूप से संपादित करना होगा।

संस्करण निर्दिष्ट प्रारूप

अन्य पैकेज प्रबंधकों के समान, जूलिया पैकेज मैनेजर सिमेंटिक वर्जनिंग (सेवर) का सम्मान करता है। एक उदाहरण के रूप में, एक संस्करण निर्दिष्ट किया जाता है जैसे कि 1.2.3 इसलिए इसे संस्करणों के साथ संगत माना जाता है [1.2.3 - 2.0.0) जहां ) एक गैर-समावेशी ऊपरी सीमा है। अधिक विशेष रूप से, एक वर्जन स्पेसियर या तो एक कैरेट स्पेसियर के रूप में दिया जाता है, जैसे ^1.2.3 या एक टिल्ड स्पेसियर ~1.2.3 । कैरेट विनिर्देशक डिफ़ॉल्ट हैं और इसलिए 1.2.3 == ^1.2.3 । एक लापरवाह और टिल्ड के बीच का अंतर अगले भाग में वर्णित है। कई संस्करण विनिर्देशकों के प्रतिच्छेदन का निर्माण अल्पविराम द्वारा अलग संस्करण विनिर्देशक द्वारा किया जा सकता है।

देखभाल करने वाले निर्दिष्टकर्ता

एक कैरेट विनिर्देशक उन्नयन की अनुमति देता है जो कि सेमर के अनुसार संगत होगा। एक अद्यतन निर्भरता को संगत माना जाता है यदि नया संस्करण संस्करण विनिर्देशक में बाएं-सबसे गैर शून्य अंक को संशोधित नहीं करता है।

कुछ उदाहरण नीचे दिए गए हैं।

^1.2.3 = [1.2.3, 2.0.0)
^1.2 = [1.2.0, 2.0.0)
^1 =  [1.0.0, 2.0.0)
^0.2.3 = [0.2.3, 0.3.0)
^0.0.3 = [0.0.3, 0.0.4)
^0.0 = [0.0.0, 0.1.0)
^0 = [0.0.0, 1.0.0)

जबकि सेमर विनिर्देश में कहा गया है कि 0 के प्रमुख संस्करण वाले सभी संस्करण एक-दूसरे के साथ असंगत हैं, हमने यह विकल्प बनाया है कि 0.ab रूप में दिए गए संस्करण को 0.ab के साथ संगत माना जाता है यदि a != 0 और c >= b

टिल्ड स्पेसियर

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

~1.2.3 = [1.2.3, 1.2.4)
~1.2 = [1.2.0, 1.3.0)
~1 = [1.0.0, 2.0.0)

असमानता निर्दिष्ट करती है

संस्करण सीमाओं को निर्दिष्ट करने के लिए असमानताओं का उपयोग किया जा सकता है:

>= 1.2.3 = [1.2.3,  ∞)
≥ 1.2.3 = [1.2.3,  ∞)
= 1.2.3 = [1.2.3, 1.2.3]
< 1.2.3 = [0.0.0, 1.2.2]

एक परियोजना को प्राथमिकता देना

REPL कमांड precompile का उपयोग परियोजना में सभी निर्भरता को बढ़ाने के लिए किया जा सकता है। आप उदाहरण के लिए कर सकते हैं

(HelloWorld) pkg> update; precompile

निर्भरता को अद्यतन करने और फिर उन्हें precompile करने के लिए।

पूर्वावलोकन मोड

यदि आप केवल एक कमांड चलाने के प्रभावों को देखना चाहते हैं, लेकिन अपने राज्य को नहीं बदल सकते हैं तो आप preview एक कमांड कर सकते हैं उदाहरण के लिए:

(HelloWorld) pkg> preview add Plots

या

(HelloWorld) pkg> preview up

आपको Plots क्रमशः अपने प्रोजेक्ट में जोड़ने , या पूर्ण अपग्रेड करने के प्रभाव दिखाएगा । हालाँकि, कुछ भी स्थापित नहीं किया जाएगा और आपके Project.toml और Manifest.toml अछूते हैं।

किसी और के प्रोजेक्ट का उपयोग करना

बस परियोजना निर्देशिका और कॉल करने के लिए git clone , उदाहरण के लिए अपने प्रोजेक्ट का क्लोन तैयार cd करें

(v1.0) pkg> activate .

(SomeProject) pkg> instantiate

यदि प्रोजेक्ट में कोई मेनिफ़ेस्ट होता है, तो यह उसी स्थिति में संकुल को स्थापित करेगा जो उस मैनिफ़ेस्ट द्वारा दिया गया है। अन्यथा, यह परियोजना के साथ निर्भरता के नवीनतम संस्करणों को हल करेगा।

संदर्भ

यह खंड Pkg.jl के साथ बातचीत करने के "एपीआई मोड" का वर्णन करता है जो गैर-संवादात्मक उपयोग के लिए अनुशंसित है, अर्थात स्क्रिप्ट में। आरईपीएल मोड संकुल में (जुड़े संस्करण, UUID के साथ, यूआरएल आदि) तार से,, पार्स कर रहे हैं, उदाहरण के लिए "Package#master" , "[email protected]" , "www.mypkg.com/MyPkg#my/feature" । एपीआई मोड में सरल कमांड के लिए तर्कों के रूप में स्ट्रिंग्स का उपयोग करना संभव है (जैसे Pkg.add(["PackageA", "PackageB"]) , अधिक जटिल कमांड, जैसे कि URL या संस्करण सीमा निर्दिष्ट करें, स्ट्रिंग्स पर अधिक संरचित प्रारूप का उपयोग करता है। यह एक उदाहरण का एक उदाहरण बनाकर किया जाता है, PackageSpec जो पारित हो जाता है। कार्यों में।

Pkg.PackageSpec प्रकार

PackageSpec(name::String, [uuid::UUID, version::VersionNumber])
PackageSpec(; name, url, path, rev, version, mode, level)

PackageSpec विभिन्न मेटाडेटा के साथ एक पैकेज का प्रतिनिधित्व है। यह भी शामिल है:

  • name पैकेज की।
  • पैकेज अद्वितीय है uuid
  • version पैकेज जोड़ते समय ए (उदाहरण के लिए। अपग्रेड करते समय, एक उदाहरण भी हो सकता है

द एनम UpgradeLevel

  • A url और वैकल्पिक git rev ision। rev एक शाखा का नाम या एक प्रतिबद्ध प्रतिबद्ध SHA हो सकता है।
  • एक स्थानीय रास्ता path । यह url तर्क का उपयोग करने के बराबर है, लेकिन अधिक वर्णनात्मक हो सकता है।
  • mode , जो कि एनम का एक उदाहरण है PackageMode जो PKGMODE_PROJECT या तो हो सकता है

PKGMODE_MANIFEST , के लिए चूक PKGMODE_PROJECT । उदाहरणार्थ प्रयुक्त Pkg.rm

Pkg में अधिकांश कार्य लेने Vector की PackageSpec और वेक्टर में सभी संकुल पर आपरेशन करते हैं।

नीचे REPL संस्करण और संस्करण के बीच तुलना है PackageSpec :

REPL API
Package PackageSpec("Package")
[email protected] PackageSpec(name="Package", version="0.2")
Package=a67d... PackageSpec(name="Package", uuid="a67d..."
Package#master PackageSpec(name="Package", rev="master")
local/path#feature PackageSpec(path="local/path"; rev="feature)
www.mypkg.com PackageSpec(url="www.mypkg.com")
--manifest Package PackageSpec(name="Package", mode=PKGSPEC_MANIFEST)
--major Package PackageSpec(name="Package", version=PKGLEVEL_MAJOR )
source

Pkg.PackageMode प्रकार

PackageMode

उदाहरणों के साथ एक एनम

  • PKGMODE_MANIFEST
  • PKGMODE_PROJECT

यह निर्धारित करता है कि क्या संचालन एक परियोजना या प्रकट स्तर पर किया जाना चाहिए। के लिए PackageSpec या एक तर्क के रूप में उपयोग किया जाता है Pkg.rm

source

Pkg.UpgradeLevel प्रकार

UpgradeLevel

उदाहरणों के साथ एक एनम

  • UPLEVEL_FIXED
  • UPLEVEL_PATCH
  • UPLEVEL_MINOR
  • UPLEVEL_MAJOR

निर्धारित करता है कि किसी पैकेज को कितना अद्यतन करने की अनुमति है। के लिए PackageSpec या एक तर्क के रूप में उपयोग किया जाता है Pkg.update

source

Pkg.add समारोह

Pkg.add(pkg::Union{String, Vector{String}})
Pkg.add(pkg::Union{PackageSpec, Vector{PackageSpec}})

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

उदाहरण

Pkg.add("Example") # Add a package from registry
Pkg.add(PackageSpec(name="Example", version="0.3")) # Specify version
Pkg.add(PackageSpec(url="https://github.com/JuliaLang/Example.jl", rev="master")) # From url
Pkg.add(PackageSpec(url="/remote/mycompany/juliapackages/OurPackage"))` # From path (has to be a gitrepo)

यह भी देखें PackageSpec

source

Pkg.develop समारोह

Pkg.develop(pkg::Union{String, Vector{String}})
Pkg.develop(pkgs::Union{Packagespec, Vector{Packagespec}})

पथ द्वारा ट्रैक करके विकास के लिए पैकेज उपलब्ध कराएं। यदि pkg केवल एक नाम या एक URL के साथ दिया जाता है, तो संकुल को डिफ़ॉल्ट के JULIA_PKG_DEVDIR साथ पर्यावरण चर द्वारा स्थान पर डाउनलोड किया जाएगा .julia/dev

यदि pkg एक स्थानीय पथ के रूप में दिया जाता है, तो उस पथ के पैकेज को ट्रैक किया जाएगा।

उदाहरण

# By name
Pkg.develop("Example")

# By url
Pkg.develop(PackageSpec(url="https://github.com/JuliaLang/Compat.jl"))

# By path
Pkg.develop(PackageSpec(path="MyJuliaPackages/Package.jl")

यह भी देखें PackageSpec

source

Pkg.activate समारोह

Pkg.activate([s::String]; shared::Bool=false)

पर्यावरण को सक्रिय करें s । सक्रिय वातावरण वह वातावरण है जिसे पैकेज कमांड को निष्पादित करके संशोधित किया जाता है। पथ सक्रिय है के लिए तर्क निम्नानुसार है:

  • अगर shared है true , पहले मौजूदा नामित पर्यावरण s डिपो ढेर में डिपो से सक्रिय हो जाएगा। यदि ऐसा कोई वातावरण मौजूद नहीं है, तो पहले डिपो में उस वातावरण को बनाएं और सक्रिय करें।
  • यदि s कोई मौजूदा पथ है, तो उस पथ पर पर्यावरण को सक्रिय करें।
  • यदि s वर्तमान परियोजना में एक पैकेज है और s एक पथ पर नज़र रख रहा है, तो ट्रैक किए गए पथ पर पर्यावरण को सक्रिय करें।
  • एल्स, s एक गैर-मौजूदा पथ के रूप में व्याख्या की जाती है, उस पथ को सक्रिय करें।

यदि कोई तर्क नहीं दिया जाता है activate , तो होम प्रोजेक्ट को सक्रिय करें। होम प्रोजेक्ट या तो --project कमांड लाइन विकल्प द्वारा जूलिया एक्ज़ीक्यूटेबल, या JULIA_PROJECT एनवायरनमेंट वेरिएबल के लिए निर्दिष्ट किया गया है।

उदाहरण

Pkg.activate()
Pkg.activate("local/path")
Pkg.activate("MyDependency")
source

Pkg.rm समारोह

Pkg.rm(pkg::Union{String, Vector{String}})
Pkg.rm(pkg::Union{PackageSpec, Vector{PackageSpec}})

वर्तमान परियोजना से एक पैकेज निकालें। तो mode की pkg है PKGMODE_MANIFEST भी के सभी पुनरावर्ती निर्भरता भी शामिल प्रकट से हटाने pkg

यह भी देखें PackageSpec , PackageMode

source

Pkg.update समारोह

Pkg.update(; level::UpgradeLevel=UPLEVEL_MAJOR, mode::PackageMode = PKGMODE_PROJECT)
Pkg.update(pkg::Union{String, Vector{String}})
Pkg.update(pkg::Union{PackageSpec, Vector{PackageSpec}})

एक पैकेज अपडेट करें pkg । यदि कोई सकारात्मक तर्क नहीं दिया जाता है, तो सभी पैकेज को प्रकट में अपडेट करें यदि mode है PKGMODE_MANIFEST और यदि प्रकट और प्रोजेक्ट दोनों में पैकेज mode है PKGMODE_PROJECT । यदि कोई स्थितिगत तर्क नहीं दिया level जाता है तो यह नियंत्रित करने के लिए इस्तेमाल किया जा सकता है कि कितने पैकेजों को अपग्रेड करने की अनुमति है (प्रमुख, मामूली, पैच, फिक्स्ड)।

यह भी देखें PackageSpec , PackageMode , UpgradeLevel

source

Pkg.test समारोह

Pkg.test(; coverage::Bool=true)
Pkg.test(pkg::Union{String, Vector{String}; coverage::Bool=true)
Pkg.test(pkgs::Union{PackageSpec, Vector{PackageSpec}}; coverage::Bool=true)

पैकेज के लिए परीक्षण चलाएं pkg या यदि कोई स्थितिगत तर्क नहीं दिया जाता है test , तो वर्तमान परियोजना का परीक्षण किया जाता है (जो इस प्रकार पैकेज की आवश्यकता होती है)। किसी पैकेज का परीक्षण उसकी test/runtests.jl फ़ाइल चलाकर किया जाता है ।

परीक्षण केवल pkg और उसके (पुनरावर्ती) निर्भरता (पुनरावर्ती) के साथ एक अस्थायी वातावरण उत्पन्न करके चलाए जाते हैं । यदि कोई प्रकट मौजूद है, तो उस प्रकट संस्करण का उपयोग किया जाता है, अन्यथा पैकेज का एक संभव सेट हल और स्थापित किया जाता है।

परीक्षण के दौरान, परीक्षण-विशिष्ट निर्भरताएं सक्रिय हैं, जो परियोजना फ़ाइल में उदाहरण के लिए दी गई हैं

[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = [Test]

पैकेज के लिए कवरेज आँकड़े पास करके उत्पन्न किए जा सकते हैं coverage=true । डिफ़ॉल्ट व्यवहार कवरेज चलाना नहीं है।

परीक्षणों को check-bounds=yes डिफ़ॉल्ट रूप से और उसके साथ एक नई प्रक्रिया में निष्पादित किया जाता है startup-file=no । यदि स्टार्टअप फाइल ( ~/.julia/config/startup.jl ) का उपयोग किया जाता है, तो जूलिया को शुरू करें --startup-file=yes

source

Pkg.build समारोह

Pkg.build()
Pkg.build(pkg::Union{String, Vector{String}})
Pkg.build(pkgs::Union{PackageSpec, Vector{PackageSpec}})

गहराई-पहले पुनरावर्ती क्रम में निर्भरता के सभी और सभी के deps/build.jl लिए बिल्ड स्क्रिप्ट चलाएँ pkg । यदि कोई तर्क नहीं दिया जाता है build , तो वर्तमान परियोजना का निर्माण किया जाता है, जिसे इस प्रकार पैकेज होना चाहिए। इस फ़ंक्शन को स्वचालित रूप से एक पैकेज कहा जाता है जो पहली बार स्थापित होता है।

source

Pkg.pin समारोह

Pkg.pin(pkg::Union{String, Vector{String}})
Pkg.pin(pkgs::Union{Packagespec, Vector{Packagespec}})

वर्तमान संस्करण के लिए एक पैकेज को पिन करें ( packagespec या एक निश्चित गिट संशोधन में दिया गया है । एक पिन किया गया पैकेज कभी अपडेट नहीं किया जाता है

source

Pkg.free समारोह

Pkg.free(pkg::Union{String, Vector{String}})
Pkg.free(pkgs::Union{Packagespec, Vector{Packagespec}})

pin यदि यह मौजूद है, तो एक पैकेज को हटा देता है, या यदि पैकेज एक पथ पर नज़र रख रहा है, जैसे बाद में Pkg.develop , पंजीकृत संस्करणों पर नज़र रखने के लिए वापस जाएं।

उदाहरण

Pkg.free("Package")
Pkg.free(PackageSpec("Package"))
source

Pkg.instantiate समारोह

Pkg.instantiate()

यदि कोई Manifest.toml फ़ाइल वर्तमान प्रोजेक्ट में मौजूद है, तो उस मेनिफ़ेस्ट में घोषित सभी पैकेज डाउनलोड करें। Else, Project.toml फ़ाइलों से संभव पैकेज का एक सेट हल करें और उन्हें स्थापित करें।

source

Pkg.resolve समारोह

Pkg.resolve()

एक पथ पर नज़र रखने वाले संकुल से निर्भरता ग्राफ के लिए अंतिम परिवर्तन के साथ वर्तमान प्रकट अद्यतन करें।

source

Pkg.setprotocol! समारोह

Pkg.setprotocol!(proto::Union{Nothing, AbstractString}=nothing)

add एक यूआरएल या develop आईएनजी पैकेज के दौरान GitHub द्वारा होस्ट किए गए पैकेज तक पहुंचने के लिए उपयोग किए जाने वाले प्रोटोकॉल को सेट करें । proto == nothing पैकेज डेवलपर की पसंद को दर्शाने के साथ, 'https' के लिए चूक ।

source

Original text