मशीन सीखने की परियोजनाओं में उपकरण बनाएं, एक सिंहावलोकन

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


यह पोस्ट एक ट्यूटोरियल के बजाय एक संवाद के लिए एक निमंत्रण है। शायद आपका समाधान एकदम सही है। अगर ऐसा है तो इसके बारे में सुनना दिलचस्प होगा।

इस पोस्ट में मैं एक छोटे पायथन प्रोजेक्ट का उपयोग करूँगा और विभिन्न प्रणालियों के साथ एक ही ऑटोमेशन कार्य करूँगा:

• CMake
• PyBuilder
• pynt
• पक्की सड़क करनेवाला
• हालैंड देश का एक छोटा सिक्का
• लुइगी

पोस्ट के अंत में एक तुलना तालिका होगी।

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

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

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

बिल्ड सिस्टम का मेरा चयन न तो व्यापक है और न ही निष्पक्ष। यदि आप अपनी सूची बनाना चाहते हैं, तो विकिपीडिया एक अच्छा प्रारंभिक बिंदु हो सकता है। जैसा कि ऊपर कहा गया है, मैं CMake , PyBuilder , pynt , Paver , doit और Luigi को कवर करूंगा । इस सूची के अधिकांश उपकरण अजगर आधारित हैं और यह समझ में आता है कि परियोजना पायथन में है। यह पोस्ट उपकरण को स्थापित करने के तरीके को कवर नहीं करेगा। मुझे लगता है कि आप पायथन में काफी कुशल हैं।

मैं ज्यादातर इस कार्यक्षमता का परीक्षण करने में दिलचस्पी रखता हूं:

1. निर्भरता के साथ कुछ लक्ष्यों को निर्दिष्ट करना। मैं यह देखना चाहता हूं कि यह कैसे करना है और यह कितना आसान है।
2. वृद्धिशील बनाता है अगर जाँच कर रहा है। इसका मतलब है कि बिल्ड सिस्टम पुनर्निर्माण नहीं करेगा जो पिछले रन के बाद से नहीं बदला गया है, यानी आपको अपने कच्चे डेटा को फिर से डाउनलोड करने की आवश्यकता नहीं है। एक और चीज जो मैं देखूंगा वह है वृद्धिशील बनाता है जब निर्भरता बदल जाती है। कल्पना कीजिए कि हमारे पास निर्भरता A -> B -> C ग्राफ है A -> B -> C क्या B परिवर्तन होने पर C को फिर से बनाया जाएगा? अगर ए
3. यदि स्रोत कोड को बदला जाता है, तो पुनर्निर्माण को ट्रिगर किया जाएगा, अर्थात् हम उत्पन्न ग्राफ के पैरामीटर को बदलते हैं, अगली बार जब हम छवि का निर्माण करते हैं तो उन्हें फिर से बनाया जाना चाहिए।
4. बिल्ड कलाकृतियों को साफ करने के तरीकों की जाँच करना, अर्थात् बिल्ड के दौरान बनाई गई फ़ाइलों को हटा दें और वापस स्वच्छ स्रोत कोड में रोल करें।

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

सभी कोड GitHub पर उपलब्ध है ।

CMake

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

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

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

हमारे प्रोजेक्ट के लिए हम CMakeLists.txt नाम की एक फाइल बनाएंगे और प्रोजेक्ट के रूट में डालेंगे । चलो सामग्री की जाँच करें:

 cmake_minimum_required(VERSION 3.14.0 FATAL_ERROR) project(Cmake_in_ml VERSION 0.1.0 LANGUAGES NONE) 

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

हमारा पहला लक्ष्य आईआरआईएस डेटासेट डाउनलोड करेगा:

 SET(IRIS_URL "https://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data" CACHE STRING "URL to the IRIS data") set(IRIS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/data/raw) set(IRIS_FILE ${IRIS_DIR}/iris.csv) ADD_CUSTOM_COMMAND(OUTPUT ${IRIS_FILE} COMMAND ${CMAKE_COMMAND} -E echo "Downloading IRIS." COMMAND python src/data/download.py ${IRIS_URL} ${IRIS_FILE} COMMAND ${CMAKE_COMMAND} -E echo "Done. Checkout ${IRIS_FILE}." WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} ) ADD_CUSTOM_TARGET(rawdata ALL DEPENDS ${IRIS_FILE}) 

पहली पंक्ति पैरामीटर IRIS_URL को परिभाषित करती है, जो कॉन्फ़िगरेशन चरण के दौरान उपयोगकर्ता के संपर्क में है। यदि आप CMake GUI का उपयोग करते हैं तो आप GUI के माध्यम से इस चर को सेट कर सकते हैं:



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

ठीक है, आइए देखें कि हम इसका उपयोग कैसे कर सकते हैं। मैं वर्तमान में इसे स्थापित MinGW संकलक के साथ WIndows पर चला रहा हूं। आपको अपनी आवश्यकताओं के लिए जनरेटर सेटिंग को समायोजित करने की आवश्यकता हो सकती है (उपलब्ध जनरेटर की सूची देखने के लिए cmake --help चलाएं)। टर्मिनल को फायर करें और स्रोत कोड के मूल फ़ोल्डर में जाएं, फिर:

 mkdir overcome-the-chaos-build cd overcome-the-chaos-build cmake -G "MinGW Makefiles" ../overcome-the-chaos 

आधुनिक CMake के साथ हम सीधे CMake से परियोजना का निर्माण कर सकते हैं। यह कमांड build all कमांड का build all करेगी:

 cmake --build . 

हम उपलब्ध लक्ष्यों की सूची भी देख सकते हैं:

 cmake --build . --target help 

और हम डाउनलोड की गई फ़ाइल को निकाल सकते हैं:

 cmake --build . --target clean 

देखें कि हमें मैन्युअल रूप से स्वच्छ लक्ष्य बनाने की आवश्यकता नहीं है।

अब आइए अगले लक्ष्य पर जाएं - पूर्वप्रमाणित आईआरआईएस डेटा। Mateusz एक एकल फ़ंक्शन से दो फ़ाइलें बनाता है: processed.pickle और processed.xlsx । processed.xlsx । आप देख सकते हैं कि वह वाइल्डकार्ड के साथ rm का उपयोग करके इस एक्सेल फाइल को साफ करने के साथ कैसे चला जाता है। मुझे लगता है कि यह बहुत अच्छा तरीका नहीं है। CMake में, हमारे पास इससे निपटने के तरीके के दो विकल्प हैं। पहला विकल्प ADDITIONAL_MAKE_CLEAN_FILES निर्देशिका संपत्ति का उपयोग करना है। कोड होगा:

 SET(PROCESSED_FILE ${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.pickle) ADD_CUSTOM_COMMAND(OUTPUT ${PROCESSED_FILE} COMMAND python src/data/preprocess.py ${IRIS_FILE} ${PROCESSED_FILE} --excel data/processed/processed.xlsx WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS rawdata ${IRIS_FILE} ) ADD_CUSTOM_TARGET(preprocess DEPENDS ${PROCESSED_FILE}) # Additional files to clean set_property(DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.xlsx ) 

दूसरा विकल्प कस्टम कमांड आउटपुट के रूप में फाइलों की सूची निर्दिष्ट करना है:

 LIST(APPEND PROCESSED_FILE "${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.pickle" "${CMAKE_CURRENT_SOURCE_DIR}/data/processed/processed.xlsx" ) ADD_CUSTOM_COMMAND(OUTPUT ${PROCESSED_FILE} COMMAND python src/data/preprocess.py ${IRIS_FILE} data/processed/processed.pickle --excel data/processed/processed.xlsx WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS rawdata ${IRIS_FILE} src/data/preprocess.py ) ADD_CUSTOM_TARGET(preprocess DEPENDS ${PROCESSED_FILE}) 

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

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

और अंत में तीसरा लक्ष्य:

 SET(EXPLORATORY_IMG ${CMAKE_CURRENT_SOURCE_DIR}/reports/figures/exploratory.png) ADD_CUSTOM_COMMAND(OUTPUT ${EXPLORATORY_IMG} COMMAND python src/visualization/exploratory.py ${PROCESSED_FILE} ${EXPLORATORY_IMG} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DEPENDS ${PROCESSED_FILE} src/visualization/exploratory.py ) ADD_CUSTOM_TARGET(exploratory DEPENDS ${EXPLORATORY_IMG}) 

यह लक्ष्य मूल रूप से दूसरे के समान है।

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

आप अभी भी अपने आप को बहुत gluing करेंगे क्योंकि आपको सही चर पास करने की आवश्यकता होगी। मुझे एक कस्टम कमांड के आउटपुट का एक आसान तरीका दूसरे में नहीं दिखता है। ऐसा लगता है कि यह कस्टम लक्ष्यों के माध्यम से करना संभव है।

PyBuilder

PyBuilder भाग बहुत छोटा है। मैंने अपने प्रोजेक्ट में Python 3.7 का उपयोग किया है और PyBuilder वर्तमान संस्करण 0.11.17 इसका समर्थन नहीं करता है। प्रस्तावित समाधान विकास संस्करण का उपयोग करना है। हालाँकि वह संस्करण v9 को पाइप करने के लिए बाध्य है। लेखन के समय में पिप v19.3 है। ओह। इसके साथ थोड़ा सा चक्कर लगाने के बाद, यह मेरे लिए बिल्कुल भी काम नहीं करता था। PyBuilder मूल्यांकन एक अल्पकालिक था।

pynt

Pynt अजगर आधारित है, जिसका अर्थ है कि हम सीधे अजगर कार्यों का उपयोग कर सकते हैं। उन्हें क्लिक के साथ लपेटना और कमांड लाइन इंटरफ़ेस प्रदान करना आवश्यक नहीं है। हालाँकि, pynt शेल कमांड को निष्पादित करने में भी सक्षम है। मैं अजगर कार्यों का उपयोग करूंगा।

बिल्ड कमांड एक फ़ाइल build.py में दिए गए हैं। फ़ंक्शन डेकोरेटर्स के साथ लक्ष्य / कार्य बनाए जाते हैं। एक ही डेकोरेटर के माध्यम से टास्क निर्भरता प्रदान की जाती है।

चूँकि मैं अजगर स्क्रिप्ट का उपयोग करना चाहता हूँ, इसलिए मुझे उन्हें निर्माण स्क्रिप्ट में आयात करना होगा। पायनट में मौजूदा निर्देशिका को अजगर लिपि के रूप में शामिल नहीं किया गया है, इसलिए इस तरह से लिखना:

 from src.data.download import pydownload_file 

काम नहीं करेगा। हमें करना है:

 import os import sys sys.path.append(os.path.join(os.path.dirname(__file__), '.')) from src.data.download import pydownload_file 

मेरी आरंभिक build.py फ़ाइल इस तरह थी:

 #!/usr/bin/python import os import sys sys.path.append(os.path.join(os.path.dirname(__file__), '.')) from pynt import task from path import Path import glob from src.data.download import pydownload_file from src.data.preprocess import pypreprocess iris_file = 'data/raw/iris.csv' processed_file = 'data/processed/processed.pickle' @task() def rawdata(): '''Download IRIS dataset''' pydownload_file('https://archive.ics.uci.edu/ml/machine-learning-databases/iris/iris.data', iris_file) @task() def clean(): '''Clean all build artifacts''' patterns = ['data/raw/*.csv', 'data/processed/*.pickle', 'data/processed/*.xlsx', 'reports/figures/*.png'] for pat in patterns: for fl in glob.glob(pat): Path(fl).remove() @task(rawdata) def preprocess(): '''Preprocess IRIS dataset''' pypreprocess(iris_file, processed_file, 'data/processed/processed.xlsx') 

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

हम प्रोजेक्ट के फ़ोल्डर से pynt चला सकते हैं और सभी उपलब्ध लक्ष्यों को सूचीबद्ध कर सकते हैं:

 pynt -l 

चलो जोड़ीदार वितरण बनाते हैं:

 pynt exploratory 

यदि हम अब उसी कमांड को फिर से चलाते हैं (यानी pynt exploratory ) तो एक पूर्ण पुनर्निर्माण होगा। Pynt ने ट्रैक नहीं किया कि कुछ भी नहीं बदला है।

पक्की सड़क करनेवाला

पेवर लगभग Pynt के रूप में दिखता है। यह एक तरह से थोड़ा अलग होता है जैसे कि लक्ष्य (दूसरे डेकोरेटर @needs ) के बीच निर्भरता को परिभाषित करता है। पेवर हर बार एक पूर्ण पुनर्निर्माण करता है और वैकल्पिक तर्क वाले कार्यों के साथ अच्छी तरह से नहीं खेलता है। बिल्ड निर्देश pavement.py फ़ाइल में पाए जाते हैं।

हालैंड देश का एक छोटा सिक्का

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



ऐसी पाइपलाइन बनाने के लिए हमें लक्ष्य A में दो बार फ़ाइल outA को निर्दिष्ट करने की आवश्यकता होगी (एक लक्ष्य के परिणामस्वरूप, लेकिन यह भी लक्ष्य निष्पादन के हिस्से के रूप में नाम है)। फिर हमें बी को लक्षित करने के लिए इसे इनपुट के रूप में निर्दिष्ट करना होगा। इसलिए कुल 3 जगह हैं जहां हमें फ़ाइल outA बारे में जानकारी प्रदान करने की आवश्यकता है। और हम ऐसा करने के बाद भी, फ़ाइल outA संशोधन से लक्ष्य B का स्वत: पुनर्निर्माण नहीं होगा। इसका मतलब है कि यदि हम लक्ष्य B को बनाने के लिए outA से outA , तो outA केवल तभी जाँच करेगा यदि लक्ष्य B अप-टू-डेट है, बिना किसी जाँच के निर्भरता की। इसे दूर करने के लिए, हमें 4 बार निर्दिष्ट करने की आवश्यकता होगी - लक्ष्य बी की फ़ाइल निर्भरता के रूप में भी। मैं इसे एक खामी के रूप में देखता हूं। मेक और सीएमके दोनों ऐसी स्थितियों को सही ढंग से संभालने में सक्षम हैं।

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

 def task_preprocess(): """Preprocess IRIS dataset""" pickle_file = 'data/processed/processed.pickle' excel_file = 'data/processed/processed.xlsx' return { 'file_dep': ['src/data/preprocess.py'], 'targets': [pickle_file, excel_file], 'actions': [doit_pypreprocess], 'getargs': {'input_file': ('rawdata', 'filename')}, 'clean': True, } 

यहाँ लक्ष्य preprocess rawdata पर निर्भर करता है। निर्भरता getargs जरिये getargs जाती है। यह कहता है कि फ़ंक्शन doit_pypreprocess का तर्क input_file लक्ष्य rawdata का आउटपुट filename है। फ़ाइल dodo.py में पूरा उदाहरण देखें।

यह doit का उपयोग करने की सफलता की कहानियों को पढ़ने के लायक हो सकता है। इसमें निश्चित रूप से एक कस्टम अप-टू-डेट लक्ष्य जांच प्रदान करने की क्षमता जैसी अच्छी विशेषताएं हैं।

लुइगी

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

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

लुइगी भी अन्य प्रणालियों से अलग है कि कैसे कार्य बनाए जाते हैं। dodo.py कुछ पूर्वनिर्धारित फ़ाइल (जैसे dodo.py , pavement.py या makefile) पर कार्य नहीं करता है। बल्कि, एक अजगर मॉड्यूल नाम पारित करना होगा। इसलिए, यदि हम इसे अन्य उपकरणों के समान तरीके से उपयोग करने का प्रयास करते हैं (प्रोजेक्ट के रूट में कार्यों के साथ एक फ़ाइल रखें), तो यह काम नहीं करेगा। हमें या तो अपनी परियोजना को स्थापित करना होगा या परियोजना के पथ को जोड़कर पर्यावरण चर PYTHONPATH को संशोधित करना होगा।

लुइगी के बारे में क्या महान है जो कार्यों के बीच निर्भरता को निर्दिष्ट करने का तरीका है। प्रत्येक कार्य एक वर्ग है। विधि output लुइगी को बताता है कि कार्य के परिणाम कहां समाप्त होंगे। परिणाम एकल तत्व या सूची हो सकते हैं। विधि के requires कार्य निर्भरता निर्दिष्ट करना requires (अन्य कार्य; हालाँकि यह स्वयं से निर्भरता बनाना संभव है)। और वह यह है। टास्क ए में output रूप में जो कुछ भी निर्दिष्ट किया गया है वह टास्क बी के इनपुट के रूप में पारित किया जाएगा यदि टास्क बी ए पर निर्भर करता है।


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

इस परियोजना के लिए लुइगी कार्य फ़ाइल luigitasks.py में उपलब्ध हैं। मैं उन्हें टर्मिनल से चलाता हूं:

 luigi --local-scheduler --module luigitasks Exploratory 

तुलना

नीचे दी गई तालिका संक्षेप में बताती है कि हमारे विशिष्ट लक्ष्यों के संबंध में विभिन्न प्रणालियां कैसे काम करती हैं।