कोकोपॉड्स से स्विफ्ट पैकेज मैनेजर के लिए माइग्रेट करना



कोकोपोड्स को iOS के लिए सबसे लोकप्रिय निर्भरता प्रबंधक माना जाता है। हाल के वर्षों में, Apple अपने मूल स्विफ्ट पैकेज मैनेजर (SPM) निर्भरता प्रबंधक के विकास पर काम कर रहा है।

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

Xcode 11 की रिलीज़ के साथ, SPM iOS के लिए विकास की दुनिया में आना शुरू हुआ। अब यह पहले से ही एक पूर्ण उपकरण है जिसका उपयोग किया जा सकता है, लेकिन अभी तक सीमाएं हैं।

वर्तमान संस्करण में, SPM संसाधनों का समर्थन नहीं करता है (हम SE-0271 की प्रतीक्षा कर रहे हैं )। हमारे देश में, प्रत्येक मॉड्यूल एक परमाणु आत्मनिर्भर निर्भरता है जिसे परियोजना से जोड़ा जा सकता है, इसलिए संसाधनों की आवश्यकता होती है (स्थानीयकरण, संपत्ति)।

इस बीच, हम प्रवास की तैयारी कर सकते हैं: यह समझने के लिए कि यह कितना मुश्किल है, क्या यह स्वचालित हो सकता है और आपको किन समस्याओं का सामना करना पड़ सकता है।

कोकोपोड्स से एसपीएम में माइग्रेट क्यों करें?


  • पारिस्थितिकी तंत्र में स्वाभाविकता और एकीकरण। पहले से, Xcode एक SPM पैकेज बनाने या जोड़ने का प्रस्ताव है।
  • कोकोपोड्स के विपरीत, एक निर्भरता परियोजना पर काम करने के लिए कार्यक्षेत्र का होना आवश्यक नहीं है।
  • एक नई निर्भरता जोड़ने के बाद, आपको पूरी परियोजना को स्थापित करने और पुनर्निर्माण करने की आवश्यकता नहीं है।
  • स्थानीय निर्भरता का उपयोग करना सुविधाजनक है: फ़ोल्डर संरचना में परिवर्तन नहीं होता है, इसे तेजी से पुनर्निर्माण किया जाता है।
  • SPM , Cocoapods, Ruby ( iOS-).
  • Cocoapods Xcode Swift.
  • Example : Xcode Package.swift .
  • abstract_target: SPM .
  • blame , .
  • Ruby, .

?


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

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

कहाँ से शुरू करें?


सबसे पहले, हम आपके आश्रितों की एक पूरी सूची एकत्र करते हैं - यह पॉडफाइल.लॉक में प्रस्तुत किया गया है। आप SPMReady जैसी उपयोगिताओं का उपयोग कर सकते हैं



इसके बाद, हम उन्हें रिश्ते द्वारा समूहित करते हैं। उदाहरण के लिए, लगभग सभी घटक SMENetwork पर निर्भर करते हैं, जिसका अर्थ है कि हम उन्हें SPM में स्थानांतरित नहीं कर पाएंगे, जब तक SMENetwork स्वयं माइग्रेट न हो जाए।

फिर हम एक मॉड्यूल का चयन करते हैं, जिस पर अधिकांश मॉड्यूल निर्भर करते हैं - एसएमएन नेटवर्क।
अंत में, इस मॉड्यूल के भंडार पर जाएं, इसे एक फ़ोल्डर में जांचें और इस फ़ोल्डर की जड़ में एक मॉड्यूल बनाएं।

git clone ssh://.../smenetwork.git Developer/SMENetwork
cd Developer/SMENetwork
swift package init
Creating library package: SMENetwork
Creating Package.swift
Creating Sources/
Creating Sources/SMENetwork/SMENetwork.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/SMENetworkTests/
Creating Tests/SMENetworkTests/SMENetworkTests.swift
Creating Tests/SMENetworkTests/XCTestManifests.swift

नतीजतन, हमें मुख्य Package.swift फ़ाइल और स्रोत और परीक्षण फ़ोल्डर मिलते हैं। यदि आपके पास पहले से ही था, तो वे पीसेंगे नहीं। पैकेज ऑपरेशन उदाहरण के लिए SMENetwork.swift, SMENetworkTests.swift, XCTestManifests.swift, LinuxMain.swift फाइलें बनाई गईं, उन्हें हटाया जा सकता है।

Package.swift फ़ाइल इस तरह दिखती है:



अब SMENetwork.podspec फ़ाइल



को देखें : जैसा कि आप देख सकते हैं, स्रोत और परीक्षण अन्य फ़ोल्डरों में हैं। फ़ाइलों को स्थानांतरित करें और Cocoapods उदाहरण परियोजना का परीक्षण करें।



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





SPM के लिए, आपको एक उदाहरण प्रोजेक्ट बनाने की आवश्यकता नहीं है: Xcode में सिर्फ Package.swift खोलें और यह निर्भरता को डाउनलोड और कनेक्ट करेगा, हमारे विनिर्देश के अनुसार लक्ष्य बनाएँ। हम केवल चला सकते हैं।



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



पैकेज संकलित करता है, परीक्षण संकलन करता है, लेकिन विफल रहता है।



और यहां हम पैकेज में संसाधनों की कमी की सीमा में भागते हैं, परीक्षण मोक्स पर आधारित होते हैं जो झूठ बोलते हैं, हम SE-0271 की प्रतीक्षा कर रहे हैं ...

संपूर्ण


कोकोपोड्स से एसपीएम में स्विच करना आसान है। कदम स्पष्ट हैं, लेकिन प्रवाह नीरस है और स्वचालन की आवश्यकता है।

बहुत प्रयास के बिना, आप .podspec फ़ाइल से एक पैकेज बना सकते हैं और उसे रिपॉजिटरी में भेज सकते हैं। और सबसे महत्वपूर्ण बात - आप एक परियोजना के साथ आगे बढ़ सकते हैं, और दूसरा कोकोपोड्स पर रहेगा। वह चाहे तो जरूर।

All Articles