Django प्रोजेक्ट वर्किंग डायरेक्टरी स्ट्रक्चर के लिए बेस्ट प्रैक्टिस

Question

मुझे पता है कि वास्तव में कोई सही तरीका नहीं है। हालांकि मैंने पाया है कि एक निर्देशिका संरचना बनाना कठिन है जो अच्छी तरह से काम करती है और हर डेवलपर और प्रशासक के लिए स्वच्छ रहती है। गिटहब पर अधिकांश परियोजनाओं में कुछ मानक संरचना है। लेकिन यह पीसी पर अन्य फ़ाइलों और सभी परियोजनाओं को व्यवस्थित करने का एक रास्ता नहीं दिखाता है।

विकास मशीन पर इन सभी निर्देशिकाओं को व्यवस्थित करने का सबसे सुविधाजनक तरीका क्या है? आप उन्हें कैसे नाम देते हैं, और आप इसे सर्वर से कैसे कनेक्ट और तैनात करते हैं?

• परियोजनाएँ (सभी परियोजनाएँ जिन पर आपका काम चल रहा है)
• स्रोत फ़ाइलें (स्वयं एप्लिकेशन)
• रिपॉजिटरी की वर्किंग कॉपी (मैं git का उपयोग करता हूं)
• आभासी वातावरण (मैं इस परियोजना के पास रखना पसंद करता हूं)
• स्थिर रूट (संकलित स्थिर फ़ाइलों के लिए)
• मीडिया रूट (अपलोड की गई मीडिया फ़ाइलों के लिए)
• README
• लाइसेंस
• दस्तावेजों
• रेखाचित्र
• उदाहरण (एक उदाहरण परियोजना जो इस परियोजना द्वारा प्रदान की गई एप्लिकेशन का उपयोग करती है)
• डेटाबेस (केस साइक्लाइट का उपयोग किया जाता है)
• कुछ और जो आपको प्रोजेक्ट पर सफल काम के लिए चाहिए

जिन समस्याओं को मैं हल करना चाहता हूं:

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

Answer 1

दो प्रकार के Django "प्रोजेक्ट्स" हैं जो मेरी ~/projects/निर्देशिका में हैं, दोनों में थोड़ी अलग संरचना है:

• स्टैंड-अलोन वेबसाइट्स
• प्लग करने योग्य अनुप्रयोग

स्टैंड-अलोन वेबसाइट

ज्यादातर निजी परियोजनाएं, लेकिन होना जरूरी नहीं है। यह आमतौर पर इस तरह दिखता है:

~/projects/project_name/

docs/               # documentation
scripts/
  manage.py         # installed to PATH via setup.py
project_name/       # project dir (the one which django-admin.py creates)
  apps/             # project-specific applications
    accounts/       # most frequent app, with custom user model
    __init__.py
    ...
  settings/         # settings for different environments, see below
    __init__.py
    production.py
    development.py
    ...

  __init__.py       # contains project version
  urls.py
  wsgi.py
static/             # site-specific static files
templates/          # site-specific templates
tests/              # site-specific tests (mostly in-browser ones)
tmp/                # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...

समायोजन

मुख्य सेटिंग्स उत्पादन वाले हैं। अन्य फ़ाइलें (जैसे। staging.py, development.py) बस आयात सब कुछ से production.pyऔर केवल आवश्यक चर ओवरराइड।

प्रत्येक वातावरण के लिए, अलग-अलग सेटिंग्स फ़ाइलें हैं, उदाहरण के लिए। उत्पादन, विकास। मेरे पास कुछ परियोजनाएं हैं जिनमें परीक्षण (टेस्ट रनर के लिए), स्टेजिंग (अंतिम तैनाती से पहले एक जांच के रूप में) और हरोकू (हरोकू में तैनाती के लिए) भी हैं।

आवश्यकताएँ

मैं सीधे setup.py में आवश्यकताओं को निर्दिष्ट। केवल उन विकास / परीक्षण वातावरण के लिए जो मुझे चाहिए requirements_dev.txt।

कुछ सेवाओं (जैसे। हरोकू) को requirements.txtरूट डायरेक्टरी में होना आवश्यक है।

setup.py

का उपयोग करते हुए परियोजना को तैनात करते समय उपयोगी setuptools। यह जोड़ता manage.pyहै PATH, इसलिए मैं manage.pyसीधे (कहीं भी) चला सकता हूं ।

प्रोजेक्ट-विशिष्ट एप्लिकेशन

मैं इन ऐप्स को project_name/apps/डायरेक्टरी में डालता था और रिलेटिव इंपोर्ट का इस्तेमाल करके इन्हें इम्पोर्ट करता था।

टेम्प्लेट / स्थिर / स्थानीय / परीक्षण फ़ाइलें

मैंने इन टेम्प्लेट्स और स्टैटिक फाइल्स को ग्लोबल टेम्प्लेट / स्टैटिक डायरेक्टरी में डाला, न कि प्रत्येक ऐप के अंदर। इन फ़ाइलों को आमतौर पर लोगों द्वारा संपादित किया जाता है, जो प्रोजेक्ट कोड संरचना या अजगर के बारे में बिल्कुल भी परवाह नहीं करते हैं। यदि आप फुल-स्टैक डेवलपर अकेले या छोटी टीम में काम कर रहे हैं, तो आप प्रति-ऐप टेम्प्लेट / स्टैटिक डायरेक्टरी बना सकते हैं। यह वास्तव में सिर्फ स्वाद की बात है।

लोकेल के लिए भी यही लागू होता है, हालांकि कभी-कभी अलग-अलग लोकल डायरेक्टरी बनाने के लिए यह सुविधाजनक होता है।

टेस्ट आमतौर पर प्रत्येक ऐप के अंदर रखने के लिए बेहतर होते हैं, लेकिन आमतौर पर कई एकीकरण / कार्यात्मक परीक्षण होते हैं जो एक साथ काम करने वाले अधिक ऐप का परीक्षण करते हैं, इसलिए वैश्विक परीक्षण निर्देशिका को समझ में आता है।

Tmp निर्देशिका

वीसीएस से बाहर रखा गया परियोजना रूट में अस्थायी निर्देशिका है। इसका उपयोग विकास के दौरान मीडिया / स्टेटिक फाइल और साइक्लाइट डेटाबेस को संग्रहीत करने के लिए किया जाता है। Tmp में सब कुछ बिना किसी समस्या के कभी भी हटाया जा सकता है।

virtualenv

मैं virtualenvwrapperसभी स्थानों को ~/.venvsनिर्देशिका में पसंद करता हूं और रखता हूं , लेकिन आप tmp/इसे एक साथ रखने के लिए इसे अंदर रख सकते हैं।

परियोजना का खाका

मैंने इस सेटअप के लिए प्रोजेक्ट टेम्पलेट बनाया है, django-start-template

तैनाती

इस परियोजना की तैनाती निम्नलिखित है:

source $VENV/bin/activate
export DJANGO_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt

# Update database, static files, locales
manage.py syncdb  --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages

# restart wsgi
touch project_name/wsgi.py

आप rsyncइसके बजाय का उपयोग कर सकते हैं git, लेकिन फिर भी आपको अपने वातावरण को अपडेट करने के लिए कमांड के बैच को चलाने की आवश्यकता है।

हाल ही में, मैंने [django-deploy][2]ऐप बनाया , जो मुझे पर्यावरण को अद्यतन करने के लिए एकल प्रबंधन कमांड चलाने की अनुमति देता है, लेकिन मैंने इसे केवल एक परियोजना के लिए उपयोग किया है और मैं अभी भी इसके लिए प्रयोग कर रहा हूं।

रेखाचित्र और ड्राफ्ट

टेम्प्लेट का ड्राफ्ट मैं वैश्विक templates/निर्देशिका के अंदर रखता हूं । मुझे लगता है कि कोई sketches/परियोजना रूट में फ़ोल्डर बना सकता है , लेकिन अभी तक इसका उपयोग नहीं किया है।

प्लग करने योग्य अनुप्रयोग

ये ऐप आमतौर पर ओपन-सोर्स के रूप में प्रकाशित करने के लिए तैयार हैं। मैंने django-forme से नीचे उदाहरण लिया है

~/projects/django-app/

docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...

निर्देशिकाओं का नाम स्पष्ट है (मुझे आशा है)। मैंने ऐप डायरेक्टरी के बाहर टेस्ट फाइल रखी, लेकिन यह वास्तव में मायने नहीं रखता। यह प्रदान करना महत्वपूर्ण है READMEऔर setup.py, इसलिए पैकेज आसानी से स्थापित हो जाता है pip।

Comments

धन्यवाद! मुझे आपकी संरचना पसंद है। इसने मुझे उपयोगी विचार दिए। आवश्यकताओं के लिए setup.py का उपयोग करने और PATH में manage.py स्थापित करने के बारे में अच्छे अंक। क्या आप कृपया बता सकते हैं कि आप अंतिम कार्य कैसे करते हैं? 'Tmp' dir के बारे में भी अच्छी बात है। मैं इसे 'स्थानीय' नाम देना चाहता हूं, फिर मेरे पास 'env', 'tmp' और कुछ भी अंदर हो सकता है। यह gitignore के साथ बहुत अधिक सौदे होने की समस्या को हल करता है। एक नई समस्या यह है कि यह नाम 'लोकेल' के बहुत करीब है। शायद 'लोकल' को कोर ऐप 'प्रोजेक्ट_नाम' में ले जाना समझ में आता है, निश्चित नहीं। बस खराब नाम के कारण संरचना को बदलना नहीं चाहते हैं। कोई सुझाव?

— raacer

Setup.py का उपयोग करते समय, scriptsकीवर्ड तर्क जोड़ें : github.com/elvard/django-start-template/blob/master/project/… मुझे पसंद है tmpक्योंकि यह "कुछ अस्थायी" सुझाता है जिसे कभी भी हटाया जा सकता है। टॉपलेवल localeडीआईआर आवश्यक नहीं है, आप इसे कहीं भी रख सकते हैं। मुझे यह पसंद है कि यह स्थिर / टेम्प्लेट डायर के अनुरूप हो।

— टॉमस एर्लिच

दूसरी फ़ाइलों को कॉपी किए बिना स्रोत फ़ाइलों की कई प्रतियां बनाने की क्षमता के लिए मेरी आवश्यकता सीधे हल नहीं होती है। लेकिन लक्ष्य अभी भी git checkoutपरियोजना निर्देशिका का क्लोनिंग करते समय केवल एक dir 'tmp' को छोड़कर या उपयोग करके संग्रहीत किया जा सकता है । तो ऐसा लगता है कि आपकी संरचना सभी आवश्यकताओं को पूरा करती है, और यह बिना किसी संदेह के नियमित आधार पर उपयोग करने के लिए पर्याप्त है। मैं आपका जवाब स्वीकार कर रहा हूं। धन्यवाद।

— raacer

धन्यवाद। मुझे अभी भी समझ में नहीं आया कि "अन्य फ़ाइलों की नकल के बिना स्रोत फ़ाइलों की कई प्रतियां बनाने की क्षमता" से आपका क्या मतलब है। Tweaked rsync कमांड करेगा, लेकिन इसका मतलब यह नहीं है कि आप क्या कहेंगे ...

— Tomáš Ehrlich

मैं आमतौर पर srcप्रोजेक्ट रूट के अंदर dir बनाता हूं । यह स्रोत फ़ाइलों और गिट रिपॉजिटरी रूट की वर्किंग कॉपी है। - मैं इस निर्देशिका के कई प्रतियां बना सकते हैं src, src.bak, src_tmpऔर पर इतना। जैसे अन्य गैर रेपो dirs env, tmp, media, backupएक ही स्तर पर रहते हैं। इसलिए मैं बस cp -r src src.bakकिसी भी समय मैं git के साथ कुछ प्रयोग करना चाहता हूं या बाहरी टूल के साथ संस्करणों की तुलना करना चाहता हूं। जब आपके पास अपनी रिपॉजिटरी के अंदर स्थानीय फाइलें होती हैं, तो मेरे पास मेरी स्थानीय फाइलों के अंदर भंडार होता है (इसके विपरीत)। मेरे srcदिर का बेहतर नाम है repo।

— raacer

Answer 2

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

परियोजनाएँ
मेरी व्यक्तिगत निर्देशिका में एक मुख्य फ़ोल्डर है जहाँ मैं उन सभी परियोजनाओं को बनाए रखता हूँ जहाँ मैं काम कर रहा हूँ।

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

project_repository_folder/
    .gitignore
    Makefile
    LICENSE.rst
    docs/
    README.rst
    requirements.txt
    project_folder/
        manage.py
        media/
        app-1/
        app-2/
        ...
        app-n/
        static/
        templates/
        project/
            __init__.py
            settings/
                __init__.py
                base.py
                dev.py
                local.py
                test.py
                production.py
            ulrs.py
            wsgi.py

Django डेवलपर्स के बीच रिपॉजिटरी गिट या मर्क्यूरियल सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली है। और बैकअप GitHub और Bitbucket के लिए सबसे लोकप्रिय होस्टिंग सेवाएं ।

आभासी पर्यावरण
मैं virtualenv और virtualenvwrapper का उपयोग करता हूं। दूसरे को स्थापित करने के बाद, आपको अपनी कार्यशील निर्देशिका स्थापित करने की आवश्यकता है। मेरा / मेरे / होम / envs निर्देशिका पर है, क्योंकि यह virtualenvwrapper स्थापना गाइड पर अनुशंसित है। लेकिन मुझे नहीं लगता कि सबसे महत्वपूर्ण बात यह है कि इसे कहां रखा गया है। आभासी वातावरण के साथ काम करते समय सबसे महत्वपूर्ण चीज आवश्यकताओं को रखना है।

pip freeze -l > requirements.txt 

स्टेटिक रूट
प्रोजेक्ट फ़ोल्डर

मीडिया रूट
प्रोजेक्ट फ़ोल्डर

README
रिपोजिटरी रूट

LICENSE
रिपोजिटरी रूट

दस्तावेज़
रिपॉजिटरी रूट। यह अजगर पैकेज आपके दस्तावेज़ को आसान बनाने में आपकी मदद कर सकते हैं:

• reStructuredText
• गूढ़ व्यक्ति

रेखाचित्र

उदाहरण

डेटाबेस

Comments

अपना अनुभव बांटने के लिये धन्यवाद। आपकी संरचना में बहुत सारे 'प्रोजेक्ट *' डायरेक्टरीज़ हैं। आप शायद वास्तविक जीवन में ऐसे नामों का उपयोग नहीं करते हैं, है ना? मान लीजिए कि हमारे पास एक 'टूडू' प्रोजेक्ट है। ऐसे मामलों में आप इन डायर का नाम कैसे देते हैं? आपकी वर्तमान संरचना में जो समस्या मुझे दिखाई दे रही है, वह गैर-रिपोजिटरी फ़ाइलों के साथ रिपॉजिटरी को मिला रही है (जैसा कि आपने ऊपर उल्लेख किया है)। यह किसी भी कूड़ेदान को .gitignore में जोड़ने के लिए कष्टप्रद हो सकता है, है ना? एक और संदिग्ध बात यह है कि परियोजना से अभी तक env dir रख रहा है। क्या इस का कोई मतलब निकलता है? क्यों नहीं बनाने के लिए ~ / डॉक्स, ~ / स्टैटिक्स और इतने पर? यहां तक ​​कि git को सोर्स फाइल्स के पास बैठना पसंद है।

— raacer

मैं उन्हें नाम दूंगा: "todo_project" -> todo -> todo (या शायद todoapp)। मुझे लगता है कि direcectory hierarchy की जड़ में रिपॉजिटरी फोल्डर का होना महत्वपूर्ण है। लेकिन, सिर्फ मेरी राय है। पर्यावरण निर्देशिका के बारे में, जब आपको उत्पादन वातावरण को सेटअप करने की आवश्यकता होती है, तो आपको बस टाइपिंग के साथ किया जाता है: पाइप स्थापित -U-आवश्यकताएँ आवश्यकताएँ। लेकिन, जैसा कि मैंने कहा, सब कुछ के लिए एक समाधान नहीं है।

— cor

तो मुख्य ऐप का मार्ग "प्रोजेक्ट / टूडू_प्रोजेक्ट / टूडू / टूडू" है। शब्द "प्रोजेक्ट" दो बार दोहराया गया, और शब्द "टूडू" तीन बार दोहराया गया। यह "प्रोजेक्ट / प्रोजेक्ट / my_project / project_dir / प्रोजेक्ट / प्रोजेक्ट" जैसा लगता है। नाम बहुत अस्पष्ट हैं। यह एक बड़ी समस्या है जिसे मैं अपनी निर्देशिका संरचना में हल करने की कोशिश कर रहा हूं। मैं पदानुक्रम को समझना आसान बनाने के लिए निर्देशिकाओं का नाम देना चाहता हूं। रिपॉजिटरी रूट के बारे में क्या आप बता सकते हैं कि यह महत्वपूर्ण क्यों है? आप यह भी बता सकते हैं कि मुख्य परियोजना के बाहर envs रखने के बारे में क्या अच्छा है?

— raacer

Answer 3

मुझे नई settings/निर्देशिका बनाना पसंद नहीं है । मैं बस नाम की फाइलें जोड़ता हूं settings_dev.pyऔर settings_production.pyइसलिए मुझे इसे संपादित करने की आवश्यकता नहीं है BASE_DIR। नीचे का दृष्टिकोण इसे बदलने के बजाय डिफ़ॉल्ट संरचना को बढ़ाता है।

mysite/                   # Project
    conf/
        locale/
            en_US/
            fr_FR/
            it_IT/
    mysite/
        __init__.py
        settings.py
        settings_dev.py
        settings_production.py
        urls.py
        wsgi.py
    static/
        admin/
            css/           # Custom back end styles
        css/               # Project front end styles
        fonts/
        images/
        js/
        sass/
    staticfiles/
    templates/             # Project templates
        includes/
            footer.html
            header.html
        index.html
    myapp/                 # Application
        core/
        migrations/
            __init__.py
        templates/         # Application templates
            myapp/
                index.html
        static/
            myapp/
                js/  
                css/
                images/
        __init__.py
        admin.py
        apps.py
        forms.py
        models.py
        models_foo.py
        models_bar.py
        views.py
    templatetags/          # Application with custom context processors and template tags
        __init__.py
        context_processors.py
        templatetags/
            __init__.py
            templatetag_extras.py
    gulpfile.js
    manage.py
    requirements.txt

मुझे लगता है यह:

    settings.py
    settings_dev.py
    settings_production.py

इससे बेहतर है:

    settings/__init__.py
    settings/base.py
    settings/dev.py
    settings/production.py

यह अवधारणा अन्य फाइलों पर भी लागू होती है।

---

मैं आमतौर पर node_modules/और bower_components/डिफ़ॉल्ट static/फ़ोल्डर के भीतर परियोजना निर्देशिका में जगह है ।

कुछ समय के vendor/लिए Git सबमॉड्यूल के लिए एक निर्देशिका लेकिन आमतौर पर मैं उन्हें static/फ़ोल्डर में रखता हूं ।

Answer 4

यहाँ मैं अपने सिस्टम पर अनुसरण करता हूँ।

1. सभी परियोजनाओं : वहाँ एक है अपने घर फ़ोल्डर में परियोजनाओं निर्देशिका यानी ~/projects। सभी परियोजनाएं इसके अंदर आराम करती हैं।

2. व्यक्तिगत परियोजना : मैं एक मानकीकृत संरचना टेम्पलेट का उपयोग करता हूं जिसका उपयोग कई डेवलपर्स द्वारा किया जाता है जिसे व्यक्तिगत परियोजनाओं के लिए django-skel कहा जाता है । यह मूल रूप से आपकी सभी स्थिर फ़ाइल और मीडिया फ़ाइलों और सभी का ध्यान रखता है।

3. वर्चुअल एनवायरनमेंट : सिस्टम में सभी वर्चुअल एनवायरनमेंट को स्टोर करने के लिए मेरे घर के अंदर एक वर्चस्व फ़ोल्डर है~/virtualenvs । यह मुझे लचीलापन देता है कि मुझे पता है कि मेरे पास सभी आभासी वातावरण हैं और आसानी से उपयोग कर सकते हैं

उपरोक्त 3 मेरे काम के माहौल के मुख्य विभाजन हैं।

आपके द्वारा उल्लिखित सभी अन्य भाग अधिकतर परियोजना के आधार पर परियोजना पर निर्भर होते हैं (अर्थात आप विभिन्न परियोजनाओं के लिए अलग-अलग डेटाबेस का उपयोग कर सकते हैं)। इसलिए उन्हें अपनी व्यक्तिगत परियोजनाओं में रहना चाहिए।

Comments

धन्यवाद। गैर-रिपॉजिटरी फ़ाइलों के साथ रिपॉजिटरी को मिलाते समय .itignignore में किसी भी कचरा जोड़ने के लिए यह कष्टप्रद हो सकता है। ऐसा नहीं है? मेरी कुछ परियोजनाओं में दस और अधिक ऐसी फाइलें और डीआईआर हैं, इसलिए यह मेरे लिए वास्तविक समस्या है। एक और संदिग्ध बात यह है कि परियोजना से अभी तक एनवी को दूर रखा जा रहा है। ऐसे समाधान में लचीलापन क्या है? क्यों नहीं बनाने के लिए ~ / डॉक्स, ~ / स्टेटिक्स और इतने पर? यहां तक ​​कि git को सोर्स फाइल्स के पास बैठना पसंद है। मैंने सोचा कि लचीलापन तब है जब मैं virtualenv सहित पूरे प्रोजेक्ट डायरेक्टरी को कॉपी / मूव / आर्काइव / कर सकता हूं और एक प्रोजेक्ट के भीतर कई एनवी को आसानी से बनाए रख सकता हूं

— raacer

Answer 5

Django प्रोजेक्ट कंकाल के अनुसार, उचित निर्देशिका संरचना का पालन किया जा सकता है:

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README

नवीनतम निर्देशिका संरचना के लिए https://django-project-skeleton.readthedocs.io/en/latest/structure.html देखें ।

Comments

मैं [ProjectName] / [ProjectName] दृष्टिकोण से नफरत है)!

— raacer

django-project-skeleton "Django प्रलेखन" नहीं है। यह कहना अधिक सटीक होगा "जैसा कि django-project-skeleton, ..."।

— डेविड विनीकी

Answer 6

आप https://github.com/Mischback/django-project-skeleton repository का उपयोग कर सकते हैं ।

कमांड के नीचे चलाएं:

$ django-admin startproject --template=https://github.com/Mischback/django-project-skeleton/archive/development.zip [projectname]

संरचना कुछ इस प्रकार है:

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README