एक virtualenv में कस्टम कोड कहाँ जाता है?

Question

उपयोग करते समय किस प्रकार की निर्देशिका संरचना का अनुसरण करना चाहिए virtualenv? उदाहरण के लिए, यदि मैं एक WSGI एप्लिकेशन का निर्माण कर रहा था और एक वर्चुअनव्यू बनाया, जिसे foobarमैं एक निर्देशिका संरचना के साथ शुरू करूंगा जैसे:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}

एक बार यह वातावरण बन जाने के बाद, कोई अपना स्थान कहां बनाएगा:

• अजगर फाइलें?
• स्थिर फाइलें (चित्र / आदि)?
• "कस्टम" पैकेज, जैसे कि ऑनलाइन उपलब्ध लेकिन पनीर-दुकान में नहीं मिले?

virtualenvनिर्देशिका के संबंध में ?

(मान लें कि मुझे पहले से ही पता है कि virtualenv निर्देशिका को खुद कहाँ जाना चाहिए ।)

Comments

@jkp: मैं असहमत हूं। आप एक अजगर एप्लिकेशन को कैसे लेआउट करते हैं यह इस बात से अलग है कि आप विकास के उद्देश्यों के लिए एक virtualenv के भीतर उस एप्लिकेशन का पता कैसे लगाते हैं। यह संबंधित है, लेकिन समान नहीं है। कृपया डुप्लिकेट के रूप में बंद न करें।

— 16

Answer 1

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

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

इसलिए, सामान्य तौर पर, मुझे नहीं लगता कि सवाल का एक सही उत्तर है। और, इसके बारे virtualenvमें एक अच्छी बात यह है कि यह कई अलग-अलग उपयोग मामलों का समर्थन करता है: एक सही तरीका होने की आवश्यकता नहीं है।

Comments

माना। मैं अपने हर काम के लिए virtualenv का उपयोग करता हूं, और मैं कभी भी virtualenv निर्देशिका के अंदर फाइलें नहीं रखता हूं। वर्चुअन की आपकी परियोजना संरचना पर कोई प्रभाव नहीं पड़ता है; बस virtualenv को सक्रिय करें (या इसके बिन / अजगर का उपयोग करें), और अपनी फ़ाइलों पर काम करें जहाँ भी आप उन्हें वैसे भी करेंगे।

— कार्ल मेयर

मैं भी तहे दिल से सहमत हूं। जब भी मैं अपने virtualenv (मैं उपयोग करता हूं ) के अंदर किसी भी फाइल को कभी भी छूता हूं virtualenvwrapper, जब मैं postactivateऔर postdeactivateहुक संपादित करना चाहता हूं ।

— ठाणे ब्रिमहल

इस प्रश्न में अन्य उत्तरों में देखे गए प्रश्न सहित व्यापार विकल्पों सहित विभिन्न विकल्पों के ठोस, व्यावहारिक उदाहरणों के साथ प्रश्न को बेहतर तरीके से प्रस्तुत किया जाएगा।

— andyfeller

यह आपकी परियोजना को virtualenvनिर्देशिका के लिए अलग रखने के लिए क्लीनर है , लेकिन virtualenvसिस्टम पायथन से तुलना करना बेकार है, क्योंकि इसका उद्देश्य virtualenvटूटी हुई निर्भरता को ठीक करना और परियोजनाओं को अलग करना है, ताकि वे विभिन्न पैकेज संस्करणों और यहां तक ​​कि अजगर संस्करणों का उपयोग कर सकें (मुझे एहसास है कि यह पूर्व लिखा गया था) -python3)। साझा करने के लिए ऐप्स को अनुमति देना वैसे ही virtualenvउपयोग कर रहा है virtualenvजैसे कि यह सिस्टम पाइथन था, उन्हीं मुद्दों के प्रति संवेदनशील होते हुए ऐप को छोड़ने के लिए तैयार किया गया है जिन्हें virtualenv को हल करने के लिए डिज़ाइन किया गया है। There should be one obvious way to do it; तार्किक रूप से 1: 1

— दावोस

@ नीड: कुछ सर्वोत्तम प्रथाओं को प्राप्त करने की कोशिश कर रहा है, लेकिन यह अभी भी स्पष्ट नहीं है: यदि आपके पास दर्जनों प्रोजेक्ट हैं, प्रत्येक अपने वर्चुअनव के साथ है तो आप किस प्रोजेक्ट का उपयोग किस वर्चुनाव के साथ करते हैं? प्रत्येक फ़ोल्डर की जड़ में छोटे खोल स्क्रिप्ट जोड़ें, उस virtualenv के नाम के साथ जिसका आप इसके साथ उपयोग करते हैं?

— ccpizza

Answer 2

यदि आपके पास केवल कुछ प्रोजेक्ट्स ही हैं, तो कुछ भी नहीं, आपको हर एक के लिए एक नया वर्चस्व बनाने से रोकता है, और आपके पैकेजों को सही तरीके से रखता है:

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}
  /mypackage1
    __init__.py
  /mypackage2
    __init__.py

इस दृष्टिकोण का लाभ यह है कि आप हमेशा उस सक्रिय स्क्रिप्ट को ढूंढना सुनिश्चित कर सकते हैं जो अंदर की परियोजना से संबंधित है।

$ cd /foobar
$ source bin/activate
$ python 
>>> import mypackage1
>>>

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

  /virtualenvs
    /foobar
      /bin
        {activate, activate.py, easy_install, python}
      /include
        {python2.6/...}
      /lib
        {python2.6/...}
  /foobar
    /mypackage1
      __init__.py
    /mypackage2
      __init__.py

इस तरह से आप हमेशा नए वर्चुअन के साथ शुरू कर सकते हैं जब चीजें गलत हो जाती हैं, और आपकी प्रोजेक्ट फाइलें सुरक्षित रहती हैं।

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

$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python 
>>> import mypackage2
>>>

नियमित रूप से virtualenvs को सेट और फाड़ने वाले उपयोगकर्ताओं के लिए यह virtualenvwrapper को देखने के लिए समझ में आता है।

http://pypi.python.org/pypi/virtualenvwrapper

Virtualenvwrapper के साथ आप कर सकते हैं

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

अब आपको इस बात की चिंता नहीं है कि प्रोजेक्ट "फू" और "बार" पर काम करते समय आपके वर्चुअल्स कहां हैं:

  /foo
    /mypackage1
      __init__.py
  /bar
    /mypackage2
      __init__.py

इस तरह आप प्रोजेक्ट "फू" पर काम करना शुरू करते हैं:

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

फिर प्रोजेक्ट "बार" पर स्विच करना इस तरह सरल है:

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

बहुत साफ है, है ना?

Comments

मैं उपयोग करने के बारे में इस जवाब से दृढ़ता से सहमत हूं virtualenvwrapper। यह बड़े करीने से वर्चुअन को दूर करता है जबकि आप अभी भी सभी लाभ दे रहे हैं।

— ठाणे ब्रिम्हल

लेकिन आभासी पर्यावरण के अंदर अपना कोड डालने के बारे में दृढ़ता से असहमत हैं। यदि आप इसे फाइल सिस्टम पर प्रोजेक्ट के पास "पास" चाहते हैं तो प्रोजेक्ट venv/के समान स्तर पर एक डायरेक्टरी लगाएं BASE_DIR।

— रोब ग्रांट

Answer 3

क्योंकि virtualenvs स्थानांतरित करने योग्य नहीं हैं, मेरी राय में अपनी परियोजना फाइलों को virtualenv निर्देशिका के अंदर रखना बुरा है। वर्चुअन स्वयं एक उत्पन्न विकास / परिनियोजन विरूपण साक्ष्य (एक .pyc फ़ाइल की तरह) है, परियोजना का हिस्सा नहीं है; इसे दूर फैंकना और इसे कभी भी दोबारा बनाना आसान हो सकता है, या किसी नए तैनात होस्ट पर एक नया निर्माण करना आदि।

वास्तव में बहुत से लोग virtualenvwrapper का उपयोग करते हैं , जो वास्तविक virtualenvs को आपकी जागरूकता से लगभग पूरी तरह से हटा देता है, उन्हें सभी साइड-बाय-साइड $ HOME / .virtualenvs में डिफ़ॉल्ट रूप से रखता है।

Comments

पूरी तरह से सहमत यह बुरा अभ्यास है, यह इंगित करने के लिए महान है कि इसे दूर से उड़ाना और फिर से बनाना आसान होना चाहिए, विशेष रूप से तैनाती का परीक्षण करने और अनावश्यक आवश्यकताओं के पैकेज को दूर करने के लिए। बस जोड़ना चाहते हैं कि virtualenv का उपयोग करके स्थानांतरित करना संभव है जैसे virtualenv --relocatable myvenvकि stackoverflow.com/a/6628642/1335793 देखें क्योंकि आप का मतलब यह नहीं है कि आपको हालांकि चाहिए।

— दावोस

Answer 4

यदि आप अपनी परियोजना देते हैं setup.py, तो पाइप इसे सीधे संस्करण नियंत्रण से आयात कर सकता है।

कुछ इस तरह से करें:

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj

इस -eपरियोजना को परियोजना में रखा जाएगा myproject/src, लेकिन इसे लिंक करें myproject/lib/pythonX.X/site-packages/, इसलिए आपके द्वारा किए गए किसी भी बदलाव को तुरंत अपने स्थानीय से आयात करने वाले मॉड्यूल में उठाया जाएगा site-packages। #eggबिट पिप क्या नाम आप इसे आपके लिए बनाई गई अंडा पैकेज के लिए देना चाहता हूँ बताता है।

यदि आप उपयोग नहीं करते हैं --no-site-packages, तो यह निर्दिष्ट करने के लिए सावधान रहें कि आप -Eविकल्प के साथ virtualenv में स्थापित करना चाहते हैं