pip से uv पर जाएँ—निर्भरता संस्करण बदले बिना स्थानांतरण का तरीका

|लेखक: QUASA संपादकीय टीम|6 मिनट पढ़ने का समय
pip से uv पर जाएँ—निर्भरता संस्करण बदले बिना स्थानांतरण का तरीका

pip परियोजना के तय निर्भरता संस्करण बचाकर uv अपनाने के लिए सीधी निर्भरताएँ परियोजना विवरण में आयात करें और पुरानी निश्चित संस्करण सूची को समाधान की सीमा बनाएँ। uv की स्थानांतरण निर्देशिका इसके लिए uv add -r requirements.in -c requirements.txt आदेश देती है: सीधी निर्भरताएँ pyproject.toml में और चुने गए संस्करण uv.lock में दर्ज होते हैं।

आयात से पहले पुरानी फ़ाइलों, स्थापित पैकेजों और परीक्षण परिणामों की प्रति रखें। निश्चित संस्करणों को बनाए रखना तभी संभव है जब वे परियोजना की पायथन सीमा, लक्षित प्रणालियों और उपलब्ध पैकेज स्रोतों के साथ संगत हों। नया परिवेश बनने पर उसके परिणाम पुराने परिवेश से अलग से मिलाएँ; केवल लॉकफ़ाइल बन जाना सफल स्थानांतरण का पर्याप्त प्रमाण नहीं है।

पुराने परिवेश को तुलना का आधार बनाएँ

सबसे पहले निर्भरता फ़ाइलें सुरक्षित करें। परियोजना विवरण पहले से मौजूद हो तो उसकी प्रति भी रखें, विशेषकर समर्थित पायथन संस्करण, वैकल्पिक निर्भरताएँ और निर्माण प्रणाली का विन्यास। पुराने आभासी परिवेश में pip freeze से स्थापित पैकेजों की सूची निकालें। साथ में निर्भरता जाँच, सामान्य परीक्षण और पैकेज निर्माण के परिणाम दर्ज करें, ताकि बाद में मिले अंतर का ठोस आधार हो।

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

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

निजी पैकेज स्रोत पहले मिलाएँ

निजी पैकेज गायब दिखे तो संस्करण सीमा बदलने से पहले स्रोत का विन्यास जाँचें। संगतता निर्देशिका के अनुसार नया प्रबंधक pip.conf और PIP_INDEX_URL जैसे पुराने विन्यास अपने आप नहीं पढ़ता; उसके लिए UV_INDEX_URL या उसका अपना विन्यास उपलब्ध कराना पड़ता है। पुराने परिवेश में पैकेज मिलना इसलिए नए समाधान में भी उसके उपलब्ध होने की गारंटी नहीं है।

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

सीधी निर्भरताएँ आयात करें और संस्करण मिलाएँ

  1. मौजूदा परियोजना विवरण हो तो उसी में निर्भरताएँ जोड़ें और पहले दर्ज पायथन सीमा तथा निर्माण विन्यास बनाए रखें। नई फ़ाइल चाहिए तो उसमें ये मान पुराने निर्माण से मिलाकर दर्ज करें। सीमा अनजाने में बदलने पर पुराने निश्चित संस्करणों का समाधान विफल हो सकता है।
  2. सीधी आवश्यकताओं की अलग इनपुट फ़ाइल और सभी निश्चित संस्करणों की अलग सूची हो तो आरंभ में दिया आयात आदेश चलाएँ। इनपुट फ़ाइल बताती है कि परियोजना स्वयं क्या माँगती है; निश्चित सूची समाधान के लिए संस्करण सीमाएँ देती है। बनी लॉकफ़ाइल में प्रत्येक पुराने निश्चित पैकेज का नाम और संस्करण मिलाएँ। समाधान विफल हो तो विरोधी आवश्यकता पहचानें, सीमा को चुपचाप ढीला न करें।
  3. केवल निश्चित संस्करणों वाली फ़ाइल हो तो उसमें से परियोजना की सीधी आवश्यकताओं की अलग सूची बनाएँ और पूरी पुरानी सूची को सीमा के रूप में रखें। पूरी सूची को सीधी निर्भरता के रूप में आयात करना संभव है, लेकिन तब अप्रत्यक्ष पैकेज भी परियोजना की घोषित आवश्यकताएँ बन जाएँगे। आगे उन्हें हटाने या बदलने का असर समझना कठिन होगा।
  4. विकास के औजार अलग निर्भरता फ़ाइल में हों तो उन्हें विकास समूह में आयात करें और उनकी पुरानी निश्चित सूची भी सीमा के रूप में दें। विकास फ़ाइल मूल आवश्यकताओं को फिर शामिल करती हो तो वह संदर्भ हटाएँ, ताकि वे विकास समूह में दोबारा दर्ज न हों। स्थानीय पथ, संपादन योग्य स्थापना और Git से ली गई निर्भरताओं का स्रोत विवरण भी मिलाएँ।

अलग प्रणालियों की निश्चित सूचियों को पर्यावरण शर्तों के बिना एक साथ सीमा बनाने से टकराव हो सकता है। पहले स्पष्ट करें कि कौन सा पैकेज किस प्रणाली पर लागू है, फिर संयुक्त समाधान बनाएँ। नई लॉकफ़ाइल कई प्रणालियों के लिए प्रविष्टियाँ रख सकती है, जबकि पुरानी स्थापित पैकेज सूची केवल उस परिवेश की स्थिति दिखाती है जहाँ वह निकाली गई थी।

नई स्थापना और पुराने परिणाम की तुलना करें

आयात के बाद uv sync --locked से नया परियोजना परिवेश बनाएँ। लॉकफ़ाइल परियोजना विवरण से मेल न खाए तो यह विकल्प उसे बदलने के बजाय त्रुटि देता है। समन्वयन लॉकफ़ाइल से बाहर के अतिरिक्त पैकेज हटा सकता है; इसीलिए इसे पुराने परिवेश पर चलाने के बजाय अलग नए परिवेश में चलाना चाहिए।

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

इसके बाद वही निर्भरता जाँच, परीक्षण और निर्माण आदेश चलाएँ जिनके पुराने परिणाम सुरक्षित किए थे। परीक्षण पुराने परिवेश की वैकल्पिक निर्भरताओं या विकास समूह पर निर्भर थे तो नए परिवेश में भी उन्हें शामिल करें। केवल समान संस्करण मिलने से समान निर्माण परिणाम तय नहीं होता; स्रोत से बनने वाले पैकेज और निर्माण निर्भरताएँ अलग जाँच माँगती हैं।

निर्माण और सक्रिय परिवेश का अंतर समझें

परियोजना आदेश सामान्यतः परियोजना की .venv निर्देशिका में बने परिवेश को चुनते हैं, भले ही शेल में कोई दूसरा आभासी परिवेश सक्रिय हो। इसलिए पुराने सक्रिय परिवेश में सफल परीक्षण नई स्थापना की पुष्टि नहीं करता। सक्रिय परिवेश को ही लक्ष्य बनाना आवश्यक हो तो विकल्प स्पष्ट रूप से दें; स्थानांतरण की तुलना में अलग नया परिवेश परिणाम समझना आसान बनाता है।

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

यह भी पढ़ें:

साझा करें:

हमारे न्यूज़लेटर की सदस्यता लें

Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।

0