Cloud Composer अपग्रेड: pip warnings से आगे असली टकराव पकड़ें

Composer 2.13.9→2.10.5 अपग्रेड में evaluation warnings शोर हैं। समान Python/Composer पैकेज लोकल इंस्टॉल करें और pip से वास्तविक dependency conflicts पहचानें.

Cloud Composer वातावरण को अपग्रेड करते समय निर्भरताओं से जुड़ी चेतावनियों की एक दीवार उभर सकती है, जो वास्तविक बाधाओं को ढक देती है। एक सामान्य स्थिति है composer-2.13.9-airflow-2.9.3 से composer-2.13.9-airflow-2.10.5 पर अपग्रेड, जहां pip google-cloud-aiplatform और evaluation नाम के एक extra के बारे में बार‑बार संदेश दिखाता है। रिजॉल्वर घूमता हुआ लगता है, पर आगे बढ़ता नहीं दिखता, और यह साफ नहीं होता कि असल में किन पैकेजों की टक्कर हो रही है।

संदर्भ में समस्या

अपग्रेड के दौरान डिपेंडेंसी रिजॉल्वर बार-बार इस तरह की पंक्तियाँ प्रिंट करता है:

WARNING: google-cloud-aiplatform 0.7.1 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.7.0 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.6.0 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.5.1 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.5.0 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.4.0 does not provide the extra 'evaluation'
WARNING: google-cloud-aiplatform 0.3.1 does not provide the extra 'evaluation'

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

असल में क्या हो रहा है

चेतावनियों की बाढ़ असली कॉन्फ्लिक्ट सेट को नज़रअंदाज़ करवा देती है। व्यवहार में समस्या अक्सर आपके requirements में लगे कुछ पैकेज पिन्स से आती है, जो लक्षित Composer इमेज के बंडल किए गए संस्करणों से मेल नहीं खाते। Composer UI सटीक टकराव विवरण दिखा नहीं सकता। उसी Python संस्करण और इमेज की पैकेज सूची के साथ इंस्टॉल को लोकल में दोहराना ही ठोस असंगतियाँ उजागर करता है।

लोकल में दोहराएँ और वास्तविक टकराव सामने लाएँ

पहले, अपने Composer इमेज वाले Python से मेल खाता एक साफ वर्चुअल एनवायरनमेंट बनाएँ। यहां वर्णित मामले में इमेज Python 3.11.8 का उपयोग करती थी। आगे बढ़ने से पहले अपने इंटरप्रेटर का संस्करण जाँच लें।

python3.11 -m venv .env_sync
source .env_sync/bin/activate
python --version  # 3.11.8 अपेक्षित है
pip install --upgrade pip

इसके बाद, वही पैकेज इंस्टॉल करें जो आपकी सटीक Composer इमेज से मेल खाते हों। आधिकारिक संस्करण दस्तावेजीकरण किसी Composer बिल्ड के लिए Python संस्करण और पैकेज सेट—दोनों सूचीबद्ध करता है। उस सूची से एक requirements फ़ाइल तैयार करें। टकराव के संदर्भ में महत्वपूर्ण न्यूनतम हिस्सा कुछ ऐसा था:

apache-airflow==2.10.5+composer
google-cloud-aiplatform==1.108.0
google-cloud-bigquery==3.35.1
python-dateutil==2.9.0.post0
requests==2.32.4
backoff==2.2.1

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

अब Composer पैकेज सेट को अपने प्रोजेक्ट requirements के साथ इंस्टॉल करें और लॉग को ध्यान से देखें:

pip install -r composer-locked.txt -r local-requirements.txt

यह कदम वे कॉन्फ्लिक्ट उजागर करता है जिन्हें Composer का डिपेंडेंसी रिजॉल्वर छिपा सकता था। उदाहरण के लिए, लोकल रिजॉल्वर ने निम्नलिखित दिखाया:

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
mypackage 1.74.0 requires google-cloud-bigquery~=3.16.0, but you have google-cloud-bigquery 3.35.1 which is incompatible.
mypackage 1.74.0 requires python-dateutil~=2.8.2, but you have python-dateutil 2.9.0.post0 which is incompatible.
mypackage 1.74.0 requires requests~=2.31.0, but you have requests 2.32.4 which is incompatible.
analytics-python 1.4.post1 requires backoff==1.10.0, but you have backoff 2.2.1 which is incompatible.

यही स्पष्ट संदेश वास्तव में क्रियान्वयन योग्य होते हैं। उन्हीं सिफारिशों के अनुसार लोकल requirement पिन्स समायोजित करने से असली बाधाएँ दूर हो गईं। इसके बाद Composer वातावरण बिना अड़चन के composer-2.14.0-airflow-2.10.5 तक अपग्रेड हो गया।

यह तरीका प्रभावी क्यों है

Composer इमेज Airflow और उसके प्रोवाइडर्स के आसपास सख्त संस्करणों वाला बड़ा इकोसिस्टम साथ लाती है। जब आपके प्रोजेक्ट के पिन किए गए संस्करण उनसे टकराते हैं, तो मैनेज्ड रिजॉल्वर का आउटपुट शोरगुल भरा हो सकता है और असली कारण तक नहीं पहुंचाता। वही Python संस्करण और इमेज के पैकेज सेट के साथ परिवेश को लोकल में प्रतिबिंबित करने से pip सीधे, उपयोगी कॉन्फ्लिक्ट डायग्नोस्टिक्स दिखाता है। यदि कुछ पैकेज आपकी मशीन पर समस्याग्रस्त माने जाते हैं पर आपके प्रोजेक्ट से संबंधित नहीं हैं, तो उन्हें लोकल में बाहर रखने से आप वास्तविक असंगतियों पर ध्यान केंद्रित कर पाते हैं। Stack Overflow पर उपलब्ध मार्गदर्शन लोकल में न चलने वाले पैकेज संस्करण पहचानने में भी मदद कर सकता है।

व्यावहारिक परिणाम

evaluation से जुड़ी चेतावनियों को शांत कराने की कोशिश करने के बजाय, पूरा इंस्टॉल लोकल में दोहराने और अपनी निर्भरताओं को Composer इमेज के अनुरूप लाने पर ध्यान दें। ऊपर के मामले में google-cloud-bigquery, python-dateutil, requests और backoff के संस्करण मिलाने से बाधाएँ हट गईं और अपग्रेड सीधा हो गया।

मुख्य बातें

रिजॉल्वर की चेतावनी-लूप को लक्षण समझें, कारण नहीं। Python रनटाइम मिलाएँ, अपने प्रोजेक्ट requirements के साथ वही Composer पैकेज सेट इंस्टॉल करें, और असली टकराव बताने के लिए लोकल pip रिजॉल्वर पर भरोसा करें। पहले उन ठोस संस्करण-विसंगतियों को सुलझाएँ; इसके बाद अपग्रेड बिना अप्रत्याशित रुकावटों के आगे बढ़ना चाहिए।