بناء أدوات في مشاريع التعلم الآلي ، لمحة عامة

كنت أتساءل عن بنية / سير عمل مشروع التعلم / علم البيانات وكنت أقرأ آراء مختلفة حول هذا الموضوع. وعندما يبدأ الناس في الحديث عن سير العمل ، فإنهم يريدون أن تكون سير عملهم قابلة للتكرار. هناك الكثير من المشاركات التي تشير إلى استخدام جعل للحفاظ على سير العمل استنساخه. على الرغم من make مستقرًا جدًا ويستخدم على نطاق واسع ، إلا أنني شخصياً أحب الحلول عبر الأنظمة الأساسية. إنه عام 2019 ، وليس عام 1977. يمكن للمرء أن يجادل بأن تكوين نفسه عبارة عن منصة مشتركة ، ولكن في الواقع ستواجه بعض المشكلات وستقضي وقتًا في إصلاح الأداة بدلاً من القيام بالعمل الفعلي. لذلك قررت إلقاء نظرة على المكان والتحقق من الأدوات الأخرى المتاحة. نعم ، قررت قضاء بعض الوقت على الأدوات.


هذا المنشور هو دعوة للحوار أكثر من كونه تعليميًا. ربما الحل الخاص بك هو الكمال. إذا كان الأمر كذلك ، فسيكون من المثير للاهتمام معرفة ذلك.

في هذا المنشور ، سأستخدم مشروع Python صغيرًا وسأقوم بمهام الأتمتة نفسها مع أنظمة مختلفة:

• CMake
• PyBuilder
• pynt
• الجبان
• DOIT
• لويجي

سيكون هناك جدول مقارنة في نهاية المنشور.

تُعرف معظم الأدوات التي سأنظر إليها باسم برامج التشغيل الآلي للبناء أو أنظمة الإنشاء . هناك عدد لا يحصى من منهم في جميع النكهات والأحجام والتعقيدات المختلفة. الفكرة هي نفسها: يحدد المطور قواعد لإنتاج بعض النتائج بطريقة آلية ومتسقة. على سبيل المثال ، قد تكون النتيجة صورة ذات رسم بياني. من أجل جعل هذه الصورة يحتاج المرء إلى تنزيل البيانات ، وتنظيف البيانات والقيام ببعض التلاعب في البيانات (مثال تقليدي ، حقًا). يمكنك أن تبدأ مع اثنين من البرامج النصية قذيفة التي ستقوم بهذه المهمة. بمجرد عودتك إلى المشروع بعد عام ، سيكون من الصعب تذكر جميع الخطوات وترتيبها الذي تحتاجه لاتخاذ هذه الصورة. الحل الواضح هو توثيق جميع الخطوات. خبر جيد! تتيح لك أنظمة Build توثيق الخطوات في شكل برنامج كمبيوتر. تشبه بعض أنظمة الإنشاء نصوص الصدفة ، ولكن مع أجراس وصفارات إضافية.

أساس هذا المنشور هو سلسلة من المشاركات التي كتبها Mateusz Bednarski على سير العمل الآلي لمشروع التعلم الآلي. يشرح Mateusz وجهات نظره ويوفر وصفات لاستخدامها. أنا أشجعك على الذهاب والتحقق من مشاركاته أولا. سأستخدم رمزه في الغالب ، ولكن مع أنظمة بناء مختلفة.

إذا كنت ترغب في معرفة المزيد حول "إنشاء" ، فاتباع ذلك هو إشارات لبضع منشورات. بروك كينيدي يعطي لمحة عامة رفيعة المستوى في 5 خطوات سهلة لجعل مشروع علوم البيانات الخاصة بك مستنسخة. يقدم Zachary Jones مزيدًا من التفاصيل حول بناء الجملة والقدرات إلى جانب الروابط إلى المشاركات الأخرى. يكتب David Stevens منشورًا شديد الضجيج عن السبب الذي يجعلك مضطرًا تمامًا إلى البدء في استخدام make مكالمات على الفور. إنه يقدم أمثلة لطيفة تقارن بين الطريقة القديمة والطريقة الجديدة . صموئيل لامبا ، من ناحية أخرى ، يكتب عن سبب استخدام make فكرة سيئة.

اختياري لأنظمة البناء غير شامل ولا متحيز. إذا كنت تريد إنشاء قائمتك ، فقد تكون ويكيبيديا نقطة انطلاق جيدة. كما ذكر أعلاه ، سأغطي CMake و PyBuilder و pynt و Paver و doit و Luigi . معظم الأدوات في هذه القائمة تعتمد على الثعبان ومن المنطقي أن المشروع في بيثون. لن يغطي هذا المنشور كيفية تثبيت الأدوات. أفترض أنك ماهر في بيثون.

أنا مهتم في الغالب باختبار هذه الوظيفة:

1. تحديد اثنين من الأهداف مع التبعيات. أريد أن أرى كيف أفعل ذلك وكم هو سهل.
2. التحقق من إمكانية إنشاء تصاعدية. هذا يعني أن نظام الإنشاء لن يعيد بناء ما لم يتم تغييره منذ التشغيل الأخير ، أي أنك لست بحاجة إلى إعادة تنزيل بياناتك الأولية. شيء آخر سأبحث عنه هو إنشاءات تدريجية عندما تتغير التبعية. تخيل أن لدينا رسم بياني للتبعيات A -> B -> C هل سيتم إعادة بناء الهدف C إذا تغيرت B ؟ إذا؟
3. التحقق من تشغيل إعادة الإنشاء إذا تم تغيير شفرة المصدر ، أي أننا نغير معلمة الرسم البياني الذي تم إنشاؤه ، في المرة القادمة التي يجب أن نبني فيها الصورة.
4. التحقق من طرق تنظيف القطع الأثرية للبناء ، أي إزالة الملفات التي تم إنشاؤها أثناء الإنشاء والعودة إلى الشفرة المصدرية النظيفة.

لن أستخدم جميع أهداف الإنشاء من موقع Mateusz ، فقط ثلاثة منها لتوضيح المبادئ.

كل رمز متاح على جيثب .

CMake

CMake عبارة عن مولد سيناريو بناء ، والذي يولد ملفات الإدخال لأنظمة البناء المختلفة. واسم لتقف على جعل منصة عبر. CMake هي أداة هندسة البرمجيات. هو الشاغل الرئيسي هو بناء الملفات التنفيذية والمكتبات. يعرف CMake كيفية إنشاء أهداف من التعليمات البرمجية المصدر باللغات المدعومة. يتم تنفيذ CMake في خطوتين: التكوين والجيل. أثناء التهيئة ، يمكن تكوين البنية المستقبلية وفقًا لاحتياجاتك. على سبيل المثال ، يتم توفير المتغيرات التي يوفرها المستخدم أثناء هذه الخطوة. عادة ما يكون التوليد مباشرًا وينتج ملفات (ملفات) يمكن أن تعمل عليها الأنظمة. مع CMake ، لا يزال بإمكانك استخدام make ، ولكن بدلاً من كتابة makefile مباشرةً ، يمكنك كتابة ملف CMake ، مما يؤدي إلى إنشاء ملف التعريف لك.

مفهوم آخر مهم هو أن CMake تشجع يبني خارج المصدر . يبني خارج المصدر مصدر التعليمات البرمجية بعيدا عن أي القطع الأثرية التي تنتجها. هذا له معنى كبير بالنسبة إلى الملفات التنفيذية حيث قد يتم تجميع قاعدة بيانات مصدر واحد تحت بنيات وحدة المعالجة المركزية وأنظمة التشغيل المختلفة. ومع ذلك ، قد يتعارض هذا النهج مع الطريقة التي يعمل بها كثير من علماء البيانات. يبدو لي أن مجتمع علم البيانات يميل إلى الحصول على اقتران عالي للبيانات والرمز والنتائج.

دعونا نرى ما نحتاجه لتحقيق أهدافنا مع CMake. هناك احتمالان لتحديد الأشياء المخصصة في CMake: الأهداف المخصصة والأوامر المخصصة. لسوء الحظ ، سوف نحتاج إلى استخدام كليهما ، مما يؤدي إلى مزيد من الكتابة مقارنة بفانيلا makefile. يعتبر الهدف المخصص قديمًا دائمًا ، أي إذا كان هناك هدف لتنزيل البيانات الخام ، فستعيد CMake تنزيله دائمًا. يتيح الجمع بين الأمر المخصص والهدف المخصص الاحتفاظ بالأهداف محدثة.

لمشروعنا سنقوم بإنشاء ملف يسمى CMakeLists.txt ووضعه في جذر المشروع. دعنا تحقق من المحتوى:

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

هذا الجزء أساسي. يحدد السطر الثاني اسم المشروع والإصدار الخاص بك ، ويحدد أننا لن نستخدم أي دعم لغوي مدمج (شرط أن نسمي بيثون البرامج النصية).

سيكون هدفنا الأول تنزيل مجموعة بيانات IRIS:

 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 ، يمكنك تعيين هذا المتغير من خلال واجهة المستخدم الرسومية:



بعد ذلك ، نحدد المتغيرات مع موقع تنزيل مجموعة بيانات IRIS. ثم نضيف أمرًا مخصصًا ، والذي سينتج IRIS_FILE أثناء إخراجه. في النهاية ، نقوم بتحديد قاعدة بيانات هدف مستهدفة مخصصة تعتمد على IRIS_FILE مما يعني أنه من أجل بناء rawdata IRIS_FILE يجب بناء rawdata . يشير الخيار ALL للهدف المخصص إلى أن rawdata سيكون أحد الأهداف الافتراضية rawdata . لاحظ أنني أستخدم CMAKE_CURRENT_SOURCE_DIR أجل الاحتفاظ بالبيانات التي تم تنزيلها في المجلد المصدر وليس في مجلد CMAKE_CURRENT_SOURCE_DIR . هذا فقط لجعله نفس ماتيوس.

حسنا ، دعنا نرى كيف يمكننا استخدامها. أقوم حاليًا بتشغيله على Windows باستخدام برنامج التحويل البرمجي MinGW. قد تحتاج إلى ضبط إعداد المولد حسب احتياجاتك (قم بتشغيل cmake --help للاطلاع على قائمة المولدات المتاحة). أطلق النار على المحطة وانتقل إلى المجلد الأصل للكود المصدري ، ثم:

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

مع CMake الحديثة يمكننا بناء المشروع مباشرة من CMake. سوف يستدعي هذا الأمر build all command:

 cmake --build . 

يمكننا أيضًا عرض قائمة الأهداف المتاحة:

 cmake --build . --target help 

ويمكننا إزالة الملف الذي تم تنزيله عن طريق:

 cmake --build . --target clean 

نرى أننا لسنا بحاجة إلى إنشاء الهدف النظيف يدويًا.

الآن دعنا ننتقل إلى الهدف التالي - بيانات IRIS التي تم تجهيزها مسبقًا. يقوم Mateusz بإنشاء ملفين من وظيفة واحدة: processed.pickle and processed.xlsx . يمكنك أن ترى كيف يختفي بتنظيف ملف Excel هذا باستخدام rm مع wildcard. أعتقد أن هذا ليس مقاربة جيدة للغاية. في 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}) 

لاحظ أنه في هذه الحالة قمت بإنشاء القائمة ، لكنني لم استخدمها داخل الأمر المخصص. لا أعرف طريقة للإشارة إلى وسيطات الإخراج الخاصة بالأمر المخصص بداخلها.

شيء آخر مثير للاهتمام أن نلاحظه هو استخدام depends في هذا الأمر المخصص. لقد قمنا بتعيين التبعية ليس فقط من هدف مخصص ، بل إنه ناتج وكذلك سيناريو python. إذا لم نقم بإضافة التبعية إلى IRIS_FILE ، فلن يؤدي تعديل iris.csv يدويًا إلى إعادة إنشاء هدف preprocess . حسنًا ، يجب عدم تعديل الملفات في دليل الإنشاء يدويًا في المقام الأول. فقط نعلمك. مزيد من التفاصيل في مشاركة سام الخميسفيلد . هناك حاجة إلى الاعتماد على البرنامج النصي بيثون لإعادة بناء الهدف إذا تغير البرنامج النصي بيثون.

وأخيرا الهدف الثالث:

 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}) 

هذا الهدف هو في الأساس نفس الهدف الثاني.

أن يختتم. CMake يبدو فوضوي وأكثر صعوبة من جعل. في الواقع ، ينتقد الكثير من الناس CMake لأنه بناء جملة. في تجربتي ، سيأتي الفهم ومن الممكن تمامًا تفهم ملفات CMake المعقدة للغاية.

ستظل تقوم بالكثير من الإلتصاق بنفسك حيث ستحتاج إلى تمرير المتغيرات الصحيحة. لا أرى طريقة سهلة للإشارة إلى إخراج أمر مخصص واحد في أمر آخر. يبدو أنه من الممكن القيام بذلك عبر أهداف مخصصة.

PyBuilder

جزء PyBuilder قصير جدًا. لقد استخدمت Python 3.7 في مشروعي ولا يدعم الإصدار الحالي من PyBuilder 0.11.17. الحل المقترح هو استخدام نسخة التطوير. ومع ذلك ، يحد هذا الإصدار إلى النقطة v9. النقطة هي v19.3 اعتبارا من وقت الكتابة. المشكله. بعد العبث بها قليلاً ، لم ينجح الأمر بالنسبة لي على الإطلاق. كان تقييم PyBuilder قصير الأجل.

pynt

Pynt يعتمد على python ، مما يعني أنه يمكننا استخدام وظائف python مباشرة. ليس من الضروري لفهم بنقرة وتوفير واجهة سطر الأوامر. ومع ذلك ، pynt قادر أيضًا على تنفيذ أوامر shell. سأستخدم وظائف الثعبان.

وترد أوامر البناء في ملف build.py . يتم إنشاء الأهداف / المهام باستخدام أدوات تزيين الوظائف. يتم توفير تبعيات المهام من خلال نفس الديكور.

بما أنني أرغب في استخدام وظائف python أحتاج إلى استيرادها في البرنامج النصي للبناء. Pynt لا يتضمن الدليل الحالي كنص بيثون ، لذلك اكتب smth مثل هذا:

 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. الأمر مختلف قليلاً في طريقة واحدة تحدد التبعيات بين الأهداف (ديكور آخر @needs ). يقوم Paver بإعادة الإنشاء بالكامل في كل مرة ولا يلعب بشكل جيد مع الوظائف التي تحتوي على وسائط اختيارية. تم العثور على تعليمات البناء في ملف pavement.py .

DOIT

يبدو Doit وكأنه محاولة لإنشاء أداة أتمتة بناء حقيقية في بيثون. يمكنه تنفيذ أوامر python code و shell. يبدو واعدا جدا. ما يبدو أنه مفقود (في سياق أهدافنا المحددة) هو القدرة على التعامل مع التبعيات بين الأهداف. دعنا نقول أننا نريد إنشاء خط أنابيب صغير حيث يتم استخدام إخراج الهدف A كمدخل للهدف B. ودعونا نقول إننا نستخدم الملفات outA ، لذلك الهدف A إنشاء ملف يسمى outA .



من أجل إنشاء خط أنابيب من هذا القبيل ، سنحتاج إلى تحديد outA file مرتين في الهدف A (كنتيجة للهدف ، ولكننا نرجع أيضًا أنه اسم كجزء من التنفيذ المستهدف). بعد ذلك ، سوف نحتاج إلى تحديده كمدخل للهدف B. لذلك ، هناك 3 أماكن في المجموع نحتاج فيها إلى تقديم معلومات حول الملف outA . وحتى بعد قيامنا بذلك ، لن يؤدي تعديل الملف outA إلى إعادة outA التلقائي للهدف B. وهذا يعني أنه إذا طلبنا من Doit إنشاء الهدف B ، فسوف يتحقق doit فقط إذا كان الهدف B محدثًا دون التحقق من أي من التبعيات. للتغلب على هذا ، سنحتاج إلى تحديد outA 4 مرات - وأيضًا كتبعية ملف للهدف B. أرى ذلك بمثابة عيب. يستطيع كل من Make و CMake التعامل مع مثل هذه المواقف بشكل صحيح.

تعتمد التبعيات في doit على الملفات ويتم التعبير عنها كسلاسل. هذا يعني أن التبعيات. / myfile.txt و myfile.txt يُنظر إليهما على أنهما مختلفان. كما كتبت أعلاه ، أجد طريقة لتمرير المعلومات من الهدف إلى الهدف (عند استخدام أهداف الثعبان) غريبة بعض الشيء. الهدف لديه قائمة من القطع الأثرية التي سينتجها ، لكن الهدف الآخر لا يمكنه استخدامها. بدلاً من ذلك ، يجب أن تُرجع الدالة python ، التي تشكل الهدف ، قاموسًا ، يمكن الوصول إليه في هدف آخر. دعونا نرى ذلك على سبيل المثال:

 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 . تقول أن الوسيطة input_file للدالة doit_pypreprocess هي filename الإخراج rawdata الهدف. ألقِ نظرة على المثال الكامل في ملف dodo.py.

قد يكون من المفيد قراءة قصص نجاح استخدام doit. إنه يحتوي بالتأكيد على ميزات لطيفة مثل القدرة على توفير فحص مستهدف مخصص محدث.

لويجي

يبقى لويجي بعيدًا عن الأدوات الأخرى لأنه نظام لبناء خطوط أنابيب معقدة. لقد ظهر على راداري بعد أن أخبرني أحد الزملاء أنه حاول صنع ، ولم يكن قادرًا على استخدامه عبر Windows / Linux وانتقل إلى لويجي.

لويجي تهدف إلى أنظمة جاهزة للإنتاج. لأنه يأتي مع خادم ، والذي يمكن استخدامه لتصور المهام الخاصة بك أو للحصول على تاريخ من تنفيذ المهام. يسمى الخادم جدولة المركزية . يتوفر جدولة محلية لأغراض التصحيح.

تختلف لويجي أيضًا عن الأنظمة الأخرى بطريقة يتم بها إنشاء المهام. لا تعمل dodo.py على بعض الملفات المحددة مسبقًا (مثل dodo.py أو pavement.py أو makefile). بدلا من ذلك ، يتعين على المرء أن يمر اسم وحدة بيثون. لذلك ، إذا حاولنا استخدامه بطريقة مشابهة للأدوات الأخرى (وضع ملف به مهام في جذر المشروع) ، فلن ينجح. يتعين علينا إما تثبيت مشروعنا أو تعديل متغير البيئة PYTHONPATH عن طريق إضافة المسار إلى المشروع.

ما هو عظيم حول لويجي هو طريقة تحديد التبعيات بين المهام. كل مهمة هي فئة. يخبر أسلوب output Luigi أين ستنتهي نتائج المهمة. يمكن أن تكون النتائج عنصرًا واحدًا أو قائمة. requires الأسلوب تحديد تبعيات المهام (مهام أخرى ؛ على الرغم من أنه من الممكن إنشاء تبعية من نفسه). وهذا كل شيء. كل ما تم تحديده output في المهمة A سيتم تمريره كمدخل إلى المهمة B إذا كانت المهمة B تعتمد على المهمة A.


لويجي لا يهتم التعديلات الملف. يهتم بوجود ملف. لذلك لا يمكن تشغيل عمليات إعادة الإنشاء عند تغيير التعليمات البرمجية المصدر. لا تحتوي لويجي على وظيفة نظيفة مضمنة.

تتوفر مهام Luigi لهذا المشروع في ملف luigitasks.py . أركضهم من المحطة:

 luigi --local-scheduler --module luigitasks Exploratory 

مقارنة

يلخص الجدول التالي كيفية عمل الأنظمة المختلفة فيما يتعلق بأهدافنا المحددة.