हर प्रोजेक्ट को उसके अपने venv में अलग रखें, डिपेंडेंसी को पिन करें और एक पुनरुत्पादनीय प्रोजेक्ट संरचना अपनाएँ।
इस पाठ को Kodokon में खोलेंअपने सभी प्रोजेक्ट की डिपेंडेंसी एक ही इंटरप्रेटर में इंस्टॉल करना सीधे संस्करण-टकराव की ओर ले जाता है: प्रोजेक्ट A को requests 2.31 चाहिए, प्रोजेक्ट B को कोई असंगत संस्करण। वर्चुअल एनवायरनमेंट (venv) हर प्रोजेक्ट को अलग-थलग कर देता है: उसका अपना इंटरप्रेटर, अपना pip, अपने पैकेज। यह वह पेशेवर तौर-तरीका है जिस पर कोई मोलभाव नहीं - एक प्रोजेक्ट, एक एनवायरनमेंट, जिसे किसी भी मशीन पर हूबहू दोबारा बनाया जा सके।
python -m venv .venv
source .venv/bin/activate
# On Windows:
# .venv\Scripts\activate
python -m pip install requests
python -m pip listइंस्टॉलेशन को पुनरुत्पादनीय बनाने के लिए, संस्करणों को पिन करें। pip freeze पूरे एनवायरनमेंट को निर्यात करता है, ट्रांज़िटिव डिपेंडेंसी समेत, ठीक-ठीक संस्करणों के साथ: अधिकतम पुनरुत्पादनीयता, श्रमसाध्य अपडेट। आधुनिक तरीका इन दोनों ज़रूरतों को अलग करता है: प्रत्यक्ष डिपेंडेंसी pyproject.toml में ढीली बाध्यताओं के साथ घोषित की जाती हैं, और ठीक-ठीक इंस्टॉलेशन के लिए एक लॉक फ़ाइल बनाई जाती है। किसी छोटे प्रोजेक्ट के पैमाने पर, requirements.txt अब भी पूरी तरह सम्मानजनक है।
python -m pip freeze > requirements.txt
# On another machine:
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txtसंरचना की बात करें तो, src लेआउट ही मानक है: कोड src/<package>/ में रहता है, टेस्ट tests/ में, और कॉन्फ़िगरेशन pyproject.toml में। src फ़ोल्डर का मकसद सजावटी नहीं है: यह मौजूदा डायरेक्टरी से स्थानीय पैकेज को गलती से इंपोर्ट होने से रोकता है, जो पैकेजिंग की गलतियाँ छिपा देता - आपके टेस्ट वास्तव में इंस्टॉल किए गए पैकेज पर चलते हैं। विकास के दौरान, pip install -e . प्रोजेक्ट को एडिटेबल मोड में इंस्टॉल करता है।
mkdir -p src/billing tests
touch src/billing/__init__.py
touch src/billing/invoices.py
touch tests/test_invoices.py
touch pyproject.toml README.md .gitignore
echo ".venv/" >> .gitignore