2010-01-20 14 views
13

हर बार जब मैं SSH के माध्यम से अपने सर्वर पर लॉग ऑन मैं टाइप करने के लिए निम्नलिखित की जरूरत है:मुझे DJANGO_SETTINGS_MODULE सेट की आवश्यकता क्यों है?

export DJANGO_SETTINGS_MODULE=settings 

अगर मैं ऐसा नहीं कर manage.py मॉड्यूल के किसी भी उपयोग

मेरे manage.py निम्नलिखित है विफल रहता है जोड़ा गया कोड:

if "notification" in settings.INSTALLED_APPS: 
    from notification import models as notification 

    def create_notice_types(app, created_models, verbosity, **kwargs): 
     notification.create_notice_type("friends_invite", _("Invitation Received"), _("you have received an invitation")) 
     notification.create_notice_type("friends_accept", _("Acceptance Received"), _("an invitation you sent has been accepted")) 

    signals.post_syncdb.connect(create_notice_types, sender=notification) 
else: 
    print "Skipping creation of NoticeTypes as notification app not found" 

कोई विचार?

उत्तर

11

आपका manage.py किसी एप्लिकेशन (notifications) का संदर्भ दे रहा है। यह Django को DJANGO_SETTINGS_MODULE के बारे में शिकायत करने के लिए मजबूर करता है क्योंकि Django पर्यावरण अभी तक स्थापित नहीं किया गया है।

संयोग से, आप पर्यावरण सेटअप को मैन्युअल रूप से मजबूर कर सकते हैं, लेकिन ईमानदारी से मैं manage.py में ऐसा नहीं करूँगा। यह मेरी राय में वास्तव में एक अच्छा अभ्यास नहीं है।

यहाँ है कैसे आप कर सकते हैं मैन्युअल रूप से सेटअप किसी भी अनुप्रयोग के भीतर से Django पर्यावरण (या कार्यक्रम उस बात के लिए):

# set up the environment using the settings module 
from django.core.management import setup_environ 
from myapp import settings 
setup_environ(settings) 
+0

आपके महान उत्तर के लिए धन्यवाद। आपका मतलब है कि इसकी अनुशंसा नहीं की जाती क्योंकि पोर्टेबिलिटी कम हो जाती है? कृपया बताएं क्यों। – RadiantHex

+2

हां, यह पोर्टेबिलिटी को कम करता है। कुछ भी जो किसी अनुप्रयोग को प्रबंधन उपकरण जोड़ता है, से बचा जाना चाहिए। आवेदन और परियोजनाओं को सभी स्वतंत्र रूप से भागों को स्थानांतरित करना चाहिए। भविष्य की कल्पना करें जहां आपको किसी अन्य प्रोजेक्ट में एप्लिकेशन को स्थानांतरित करने की आवश्यकता है, या किसी मौजूदा प्रोजेक्ट से हटा दें। यह सबसे अच्छा है कि उन्हें इंटरटवाइन न करें और इसके बजाय ऐप्स के भीतर से किसी भी प्रकार की चेक (सुरक्षित रूप से) करें। – jathanism

6

आप क्योंकि यह कैसे Django क्या अपनी सेटिंग्स मॉड्यूल जानता है DJANGO_SETTINGS_MODULE वातावरण चर निर्धारित करने की आवश्यकता कहा जाता है (इसलिए आप प्रति परियोजना या परीक्षण और विकास के लिए अलग-अलग हो सकते हैं।) आप इसे से पहले स्क्रिप्ट में सेट कर सकते हैं, आप django (प्रत्यक्ष या परोक्ष रूप से) आयात करते हैं, लेकिन जब आप Django चलाते हैं तो यह बहुत अच्छा नहीं होगा प्रसंस्कृत स्क्रिप्ट्स।

सबसे आसान समाधान शायद आपके खोल की स्टार्टअप स्क्रिप्ट में DJANGO_SETTINGS_MODULE सेट करने के लिए है, इसलिए आपको इसे मैन्युअल रूप से सेट करने की आवश्यकता नहीं होगी। इसे जोड़ने के लिए सामान्य फाइलें हैं .bash_profile और .bashrc (यदि आप वास्तव में बैश का उपयोग करते हैं।)

+0

धन्यवाद थॉमस। क्या आप बैश स्क्रिप्ट के बारे में कुछ दिशा में मुझे इंगित कर सकते हैं? मैं पुट्टी के माध्यम से लॉग इन कर रहा हूं और जब कोई स्क्रिप्ट नहीं आती है तो कोई सुराग नहीं है। – RadiantHex

+1

ठीक है, जो भी ओएस या वितरण आप लॉग इन कर रहे हैं उसके लिए प्रलेखन एक अच्छी शुरुआत होगी :) लेकिन एक अच्छी शर्त सिर्फ एक ही निर्यात लाइन जोड़ रही है क्योंकि आप पहले से ही अपने .bash_profile या .bashrc फ़ाइल में उपयोग कर रहे थे, कहीं अन्य समान निर्यात लाइनों के पास। उनमें से कोई भी हर नए खोल के लिए लोड किया जाना चाहिए। –

0

डिफ़ॉल्ट रूप से, manage.py उसी निर्देशिका में एक सेटिंग मॉड्यूल की तरह दिखता है। यदि यह एक नहीं मिलता है, तो यह इसके बजाय django-admin.py का उपयोग करने के लिए संदेश के साथ बमबारी करता है। यह वास्तव में पर्यावरण को सेट नहीं करता है जब तक कि यह execute_manager चलाता है। यदि आपको अपने प्रबंधन कार्यों को कॉल करने से पहले अपने हुक चलाने की ज़रूरत है, तो मैंने जो अभ्यास देखा है, उसे प्रासंगिक ऐप के models.py में रखना है।

संबंधित मुद्दे