PYTHONPATH बनाम sys.path

Question

एक अन्य डेवलपर और मैं इस बात से असहमत हैं कि पायथन को sys.path का उपयोग किया जाना चाहिए ताकि पायथन को उपयोगकर्ता (जैसे, विकास) निर्देशिका में पायथन पैकेज मिल सके।

हम एक ठेठ निर्देशिका संरचना के साथ एक पायथन परियोजना है:

Project
    setup.py
    package
        __init__.py
        lib.py
        script.py

Script.py में, हमें करने की आवश्यकता है import package.lib। जब पैकेज साइट-पैकेज में स्थापित हो जाता है, तो script.py पा सकता है package.lib।

उपयोगकर्ता निर्देशिका से काम करते समय, हालांकि, कुछ और किया जाना चाहिए। मेरा समाधान "~ / प्रोजेक्ट" को शामिल करने के लिए अपने PYTHONPATH को सेट करना है। एक अन्य डेवलपर स्क्रिप्ट की शुरुआत में कोड की इस लाइन को डालना चाहता है:

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

ताकि पायथन को स्थानीय प्रति मिल सके package.lib।

मुझे लगता है कि यह एक बुरा विचार है, क्योंकि यह लाइन केवल डेवलपर्स या स्थानीय कॉपी से चलने वाले लोगों के लिए उपयोगी है, लेकिन मैं एक अच्छा कारण नहीं दे सकता कि यह एक बुरा विचार क्यों है।

क्या हमें PYTOHNPATH, sys.path का उपयोग करना चाहिए, या तो ठीक है?

Comments

लगता है कि वोट और उत्तर PYTHON_PATH का उपयोग करने की दिशा में बहुत मामूली झुकाव के साथ समान रूप से विभाजित होते हैं, हालांकि यह सवाल से शोर या अनजाने में पूर्वाग्रह का नमूना हो सकता है।

— एजेपी

Answer 1

यदि पथ को संशोधित करने का एकमात्र कारण उनके काम करने वाले पेड़ से काम करने वाले डेवलपर्स के लिए है, तो आपको अपने पर्यावरण को स्थापित करने के लिए एक इंस्टॉलेशन टूल का उपयोग करना चाहिए। virtualenv बहुत लोकप्रिय है, और यदि आप सेप्टूपूल का उपयोग कर रहे हैं, तो आप बस setup.py developअपने वर्तमान पायथन इंस्टॉलेशन में काम करने वाले पेड़ को अर्ध-स्थापित करने के लिए चला सकते हैं ।

Comments

क्या आप इस पर कुछ और स्पष्टीकरण दे सकते हैं? यहां तक ​​कि अगर आप एक conda / virtualenv वातावरण खड़ा करते हैं, तो यह आपके पायथन मार्ग पर टॉपवेल डायर को कैसे रखेगा?

— Compguy24

Answer 2

मुझे PYTHONPATH से नफरत है। मुझे यह प्रति-उपयोगकर्ता आधार (विशेषकर डेमन उपयोगकर्ताओं के लिए) पर भंगुर और कष्टप्रद लगता है और जैसे-जैसे प्रोजेक्ट फ़ोल्डर घूमते हैं, उन पर नज़र रखते हैं। मैं sys.pathस्टैंडअलोन परियोजनाओं के लिए इनवोक स्क्रिप्ट में बहुत अधिक सेट करूंगा ।

हालाँकि sys.path.appendऐसा करने का तरीका नहीं है। आप आसानी से डुप्लिकेट प्राप्त कर सकते हैं, और यह .pthफ़ाइलों को सॉर्ट नहीं करता है । बेहतर (और अधिक पठनीय) site.addsitedir:।

और script.pyआम तौर पर इसे करने के लिए अधिक उपयुक्त स्थान नहीं होगा, क्योंकि यह उस पैकेज के अंदर है जिसे आप पथ पर उपलब्ध कराना चाहते हैं। लाइब्रेरी मॉड्यूल निश्चित रूप से sys.pathखुद को छू नहीं होना चाहिए । इसके बजाय, आपके पास आमतौर पर पैकेज के बाहर एक हैशटैग-स्क्रिप्ट होती है, जिसका उपयोग आप ऐप को इंस्टेंट करने और चलाने के लिए करते हैं, और यह इस तुच्छ आवरण स्क्रिप्ट में आप की तरह तैनाती विवरण sys.pathडालेंगे।

Comments

इसके साथ समस्या site.addsitedirयह है कि यह एक appendपर करता है sys.path, जिसका अर्थ है कि एक स्थापित पैकेज विकास में स्थानीय पैकेज (और बालों को खींचना सुनिश्चित कर सकता है) पर पूर्वता लेगा। sys.path.insert(0...उस पर काबू पाने की जरूरत है।

— एली बेंडरस्की

@EliBendersky: होना चाहिए sys.path.insert(1। stackoverflow.com/q/10095037/125507

— endolith

Answer 3

सामान्य तौर पर मैं एक पर्यावरण चर (जैसे PYTHONPATH) की स्थापना को एक बुरा व्यवहार मानूंगा। हालांकि यह डिबगिंग के लिए ठीक हो सकता है लेकिन
नियमित अभ्यास के रूप में इसका उपयोग करना एक अच्छा विचार नहीं हो सकता है।

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

Answer 4

पहले से बताए गए कई अन्य कारणों के साथ, आप यह भी बता सकते हैं कि हार्ड-कोडिंग

sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

यह भंगुर है क्योंकि यह script.py के स्थान को निर्धारित करता है - यह केवल तभी काम करेगा जब script.py प्रोजेक्ट / पैकेज में स्थित हो। यदि उपयोगकर्ता किसी अन्य स्थान पर / समरूप स्क्रिप्ट स्क्रिप्ट (लगभग) को स्थानांतरित / कॉपी करने का निर्णय लेता है तो यह टूट जाएगा।

Answer 5

मुझे लगता है, कि इस मामले में PYTHONPATH का उपयोग करना एक बेहतर बात है, ज्यादातर इसलिए क्योंकि यह (संदिग्ध) अस्वाभाविक कोड पेश नहीं करता है।

आखिरकार, यदि आप यह सोचते हैं, तो आपके उपयोगकर्ता को उस sys.pathचीज़ की आवश्यकता नहीं है, क्योंकि आपका पैकेज साइट-पैकेज में स्थापित हो जाएगा, क्योंकि आप एक पैकेजिंग सिस्टम का उपयोग कर रहे होंगे।

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

Answer 6

पहले उल्लेखित कारणों के कारण न तो हैकिंग PYTHONPATHऔर न ही sys.pathएक अच्छा विचार है। और साइट-संकुल फ़ोल्डर में वर्तमान परियोजना को जोड़ने के लिए वास्तव में एक बेहतर तरीका है python setup.py develop, जैसा कि यहां बताया गया है :

pip install --editable path/to/project

यदि आपके पास पहले से ही अपने प्रोजेक्ट के रूट फ़ोल्डर में एक सेटअप-थ्रेड नहीं है, तो यह शुरुआत के साथ काफी अच्छा है:

from setuptools import setup
setup('project')