জাজানো প্রকল্পের কাজ পরিচালনা ডিরেক্টরি কাঠামোর সেরা অনুশীলন


173

আমি জানি কোন সঠিক উপায় নেই। তবে আমি খুঁজে পেয়েছি যে একটি ডিরেক্টরি কাঠামো তৈরি করা কঠিন যা প্রতিটি বিকাশকারী এবং প্রশাসকের পক্ষে ভালভাবে কাজ করে এবং পরিষ্কার থাকে। গিথুব-এ বেশিরভাগ প্রকল্পে কিছু মানক কাঠামো রয়েছে। তবে এটি পিসিতে অন্য ফাইল এবং সমস্ত প্রকল্পগুলি সংগঠিত করার কোনও উপায় দেখায় না।

ডেভলপমেন্ট মেশিনে এই সমস্ত ডিরেক্টরিগুলি পরিচালনা করার সবচেয়ে সুবিধাজনক উপায় কোনটি? আপনি কীভাবে তাদের নাম রাখেন এবং কীভাবে আপনি এটি সংযুক্ত করে সার্ভারে স্থাপন করবেন?

  • প্রকল্পগুলি (আপনার উপর কাজ করা সমস্ত প্রকল্প)
  • উত্স ফাইল (অ্যাপ্লিকেশন নিজেই)
  • ভান্ডারগুলির কাজের কপি (আমি গিট ব্যবহার করি)
  • ভার্চুয়াল পরিবেশ (আমি এটি প্রকল্পের নিকটে স্থাপন করতে পছন্দ করি)
  • স্ট্যাটিক রুট (সংকলিত স্ট্যাটিক ফাইলের জন্য)
  • মিডিয়া রুট (আপলোড করা মিডিয়া ফাইলগুলির জন্য)
  • README
  • লাইসেন্স
  • কাগজপত্র
  • স্কেচ
  • উদাহরণ (একটি প্রকল্প যা এই প্রকল্পের সরবরাহিত অ্যাপ্লিকেশন ব্যবহার করে)
  • ডাটাবেস (ক্ষেত্রে স্ক্লাইট ব্যবহার করা হয়)
  • আপনার প্রকল্পের সফল কাজের জন্য সাধারণত যা প্রয়োজন অন্য কিছু

আমি যে সমস্যাগুলি সমাধান করতে চাই:

  • ডিরেক্টরিগুলির ভাল নাম যাতে তাদের উদ্দেশ্য পরিষ্কার থাকে।
  • সমস্ত প্রকল্প ফাইল (ভার্চুয়ালেনভ সহ) এক জায়গায় রেখে দিচ্ছি, যাতে আমি সহজেই অনুলিপি করতে, স্থানান্তর করতে, সংরক্ষণাগারটি করতে, পুরো প্রকল্পটি সরাতে বা ডিস্ক স্পেসের ব্যবহারের অনুমান করতে পারি।
  • আমি ক্লোন করতে চাই না এমন অন্য ফাইলগুলির একক অনুলিপি রেখে পুরো অ্যাপ্লিকেশন, সংগ্রহশালা বা ভার্চুয়ালেনভের মতো কয়েকটি নির্বাচিত ফাইল সেটগুলির একাধিক অনুলিপি তৈরি করা।
  • সার্ভারে ফাইলগুলির ডান সেটটি কেবল নির্বাচিত একটি ডিয়ারকে রিসাইং করে স্থাপন করা।

উত্তর:


257

আমার ~/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কেবলমাত্র প্রয়োজনীয় ভেরিয়েবলগুলি থেকে সবকিছু আমদানি করে ওভাররাইড করে।

প্রতিটি পরিবেশের জন্য পৃথক সেটিংস ফাইল রয়েছে, যেমন। উত্পাদন, উন্নয়ন। আমার কয়েকটি প্রকল্পও রয়েছে (টেস্ট রানারের জন্য), মঞ্চায়ন (চূড়ান্ত স্থাপনার আগে একটি চেক হিসাবে) এবং হিরকু (হিরকুতে মোতায়েনের জন্য) সেটিংস।

আবশ্যকতা

আমি বরং সেটআপ.পিতে সরাসরি প্রয়োজনীয়তা নির্দিষ্ট করি। কেবল তারাই আমার উন্নয়ন / পরীক্ষা পরিবেশ আমি আছে জন্য প্রয়োজন বোধ করা requirements_dev.txt

কিছু পরিষেবা (যেমন হিরকু) requirements.txtএর মূল ডিরেক্টরিতে থাকা দরকার।

setup.py

প্রকল্প ব্যবহার করে স্থাপন করার সময় দরকারী setuptools। এটি এতে যোগ manage.pyকরে PATH, তাই আমি manage.pyসরাসরি (যে কোনও জায়গায়) চালাতে পারি ।

প্রকল্প-নির্দিষ্ট অ্যাপ্লিকেশন

আমি এই অ্যাপ্লিকেশনগুলিকে project_name/apps/ডিরেক্টরিতে রেখেছি এবং এগুলি আপেক্ষিক আমদানি ব্যবহার করে আমদানি করতাম।

টেমপ্লেট / স্থির / স্থানীয় / ফাইল পরীক্ষা করে

আমি এই টেম্পলেটগুলি এবং স্ট্যাটিক ফাইলগুলিকে গ্লোবাল টেম্পলেট / স্ট্যাটিক ডিরেক্টরিতে রেখেছি, প্রতিটি অ্যাপ্লিকেশনের অভ্যন্তরে নয়। এই ফাইলগুলি সাধারণত লোকেরা সম্পাদনা করে, যারা প্রজেক্ট কোড কাঠামো বা পাইথনকে মোটেই পরোয়া করে না। আপনি যদি পুরো স্ট্যাক বিকাশকারী একা বা একটি ছোট দলে কাজ করছেন তবে আপনি প্রতি অ্যাপ্লিকেশন টেম্পলেট / স্ট্যাটিক ডিরেক্টরি তৈরি করতে পারেন। এটি সত্যিই কেবল স্বাদের বিষয়।

একই লোকেলের জন্য প্রযোজ্য, যদিও এটি কখনও কখনও পৃথক স্থানীয় ডিরেক্টরি তৈরি করা সুবিধাজনক।

পরীক্ষাগুলি প্রতিটি অ্যাপ্লিকেশনের ভিতরে রাখার জন্য সাধারণত আরও ভাল তবে সাধারণত অনেকগুলি সংহতকরণ / কার্যকরী পরীক্ষা থাকে যা আরও বেশি অ্যাপ্লিকেশন একসাথে কাজ করে তা পরীক্ষা করে, তাই বিশ্বব্যাপী পরীক্ষার ডিরেক্টরিটি বোঝায়।

টিএমপি ডিরেক্টরি

প্রকল্পের রুটে অস্থায়ী ডিরেক্টরি রয়েছে, ভিসিএস থেকে বাদ নেই। এটি বিকাশের সময় মিডিয়া / স্ট্যাটিক ফাইল এবং স্ক্লাইট ডাটাবেস সঞ্চয় করতে ব্যবহৃত হয়। টেম্পে থাকা সমস্ত কিছু যে কোনও সময় কোনও সমস্যা ছাড়াই মুছতে পারে।

Virtualenv

আমি পছন্দ করে virtualenvwrapperসমস্ত ~/.venvsডিরেক্টরিকে ডিরেক্টরিতে রাখি তবে আপনি tmp/এটি একসাথে রাখতে ভিতরে রাখতে পারেন inside

প্রকল্পের টেম্পলেট

আমি এই সেটআপের জন্য প্রজেক্ট টেম্পলেট তৈরি করেছি, জ্যাঙ্গো-স্টার্ট-টেম্পলেট

বিস্তৃতি

এই প্রকল্পের স্থাপনা নিম্নলিখিত:

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/প্রকল্পের মূলের ফোল্ডার তৈরি করতে পারে তবে এটি এখনও ব্যবহার করেন নি।

প্লাগেবল অ্যাপ্লিকেশন

এই অ্যাপসটি সাধারণত ওপেন সোর্স হিসাবে প্রকাশের জন্য প্রস্তুত হয় are আমি জাঙ্গো-ফর্ম থেকে নীচে উদাহরণ গ্রহণ করেছি

~/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


ধন্যবাদ! আমি তোমার কাঠামো পছন্দ করি এটি আমাকে দরকারী ধারণা দিয়েছে। প্রয়োজনীয়তার জন্য setup.py ব্যবহার এবং PATH এ ম্যানেজ.পি স্থাপনের বিষয়ে ভাল পয়েন্ট points আপনি দয়া করে দেখাতে পারেন আপনি শেষ জিনিসটি কীভাবে করেন? 'টিএমপি' দির সম্পর্কেও ভাল বক্তব্য। আমি বরং এটির নাম 'স্থানীয়' রাখি, তারপরে আমার ভিতরে 'এনভি', 'টিএমপি' এবং আরও কিছু থাকতে পারে। এটি গিটিগনোরের সাথে অনেক বেশি ডিলের সমস্যা সমাধান করে। একটি নতুন সমস্যা হ'ল এই নামটি 'লোকেলের' খুব কাছে। সম্ভবত 'লোকেল' কে মূল অ্যাপ্লিকেশন 'প্রজেক্ট_নামে' স্থানান্তরিত করা বোধগম্য, নিশ্চিত নয়। খারাপ নামের কারণে কাঠামো পরিবর্তন করতে চান না। কোনও পরামর্শ?
রেসারের

Setup.py ব্যবহার করার সময়, scriptsকীওয়ার্ড যুক্তি যুক্ত করুন: github.com/elvard/django-start-template/blob/master/project/… আমার পছন্দ হয়েছে tmpকারণ এটি "সাময়িক কিছু" প্রস্তাব দেয় যা যে কোনও সময় মুছে ফেলা যায়। টপলভেল localeদির প্রয়োজনীয় নয়, আপনি এটি যে কোনও জায়গায় রাখতে পারেন। আমি ঠিক এটি স্ট্যাটিক / টেমপ্লেটগুলি ডায়ারগুলির সাথে সামঞ্জস্যপূর্ণ থাকতে চাই।
টমো এহরিলিচ

অন্য ফাইলগুলি অনুলিপি না করে উত্স ফাইলের কয়েকটি অনুলিপি তৈরির ক্ষমতার জন্য আমার প্রয়োজনীয়তা সরাসরি সমাধান করা হয় না। কিন্তু git checkoutপ্রকল্পটি ডিরেক্টরি ক্লোন করার সময় লক্ষ্যটি ব্যবহার করে বা কেবল একটি দির 'টিএমপি' বাদ দিয়ে সংরক্ষণাগারভুক্ত করা যেতে পারে । সুতরাং মনে হচ্ছে আপনার কাঠামোটি সমস্ত প্রয়োজনীয়তা পূরণ করে এবং এটি কোনও সন্দেহ ছাড়াই নিয়মিত ভিত্তিতে ব্যবহার করার পক্ষে যথেষ্ট স্পষ্ট। আমি আপনার উত্তর গ্রহণ করছি। ধন্যবাদ.
রেসারের

ধন্যবাদ. "অন্য ফাইলগুলি অনুলিপি না করে উত্স ফাইলের কয়েকটি অনুলিপি তৈরি করার ক্ষমতা" বলতে আপনার অর্থ কী তা আমি এখনও বুঝতে পারি না। Tweaked rsync কমান্ড করবেন, কিন্তু যে সম্ভবত আপনি কি বলতে চাইছেন না ...
Tomáš এরলিচ

আমি সাধারণত srcপ্রকল্পের মূলের ভিতরে ডির তৈরি করি । এটি উত্স ফাইলগুলির কার্যকরী অনুলিপি এবং গিট সংগ্রহস্থল রুট। - আমি এই ডিরেক্টরির কয়েকটি কপি করতে পারেন src, src.bak, src_tmpএবং তাই। মত অন্যান্য অ রেপো dirs env, tmp, media, backupএকই স্তরের উপর বসবাস করেন। তাই আমি cp -r src src.bakযে কোনও সময় গিটের সাথে কিছু পরীক্ষা করতে বা বাহ্যিক সরঞ্জামের সাথে সংস্করণগুলির তুলনা করতে চাই can আপনার সংগ্রহস্থলের অভ্যন্তরে স্থানীয় ফাইলগুলি থাকা অবস্থায় আমার স্থানীয় ফাইলগুলির ডিয়ারের ভিতরে আমার কাছে ভান্ডার রয়েছে (বিপরীতে)। আমার srcদির আরও ভাল নাম repo
রেসারের

19

আমার উত্তরটি আমার নিজের কাজের অভিজ্ঞতা থেকে অনুপ্রাণিত হয়েছে, এবং বেশিরভাগই জাজানো টু স্কুপস বইটিতে যা আমি অত্যন্ত সুপারিশ করি এবং যেখানে আপনি সমস্ত কিছুর আরও বিশদ ব্যাখ্যা পেতে পারেন। আমি কেবল কয়েকটি পয়েন্টের উত্তর দেব, এবং কোনও উন্নতি বা সংশোধনকে স্বাগত জানানো হবে। তবে একই উদ্দেশ্য অর্জনের জন্য আরও সঠিক শিষ্টাচার থাকতে পারে।

প্রকল্পগুলি
আমার ব্যক্তিগত ডিরেক্টরিতে আমার একটি প্রধান ফোল্ডার রয়েছে যেখানে আমি যেখানে কাজ করছি সেখানে সমস্ত প্রকল্প পরিচালনা করি।

উত্স ফাইলগুলি
আমি ব্যক্তিগতভাবে আমার প্রকল্পগুলির সংগ্রহস্থল হিসাবে জঞ্জো প্রকল্পের মূল ব্যবহার করি। তবে বইটিতে দুটি জিনিসই আলাদা করার পরামর্শ দেওয়া হয়েছে। আমি মনে করি এটি একটি আরও ভাল পদ্ধতির, তাই আমি আশা করি আমার প্রকল্পগুলিতে অগ্রগতিতে পরিবর্তন আনতে শুরু করব।

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

জাজো
বিকাশকারীদের মধ্যে রিপোজিটরি গিট বা মার্কুরিয়াল সবচেয়ে জনপ্রিয় সংস্করণ নিয়ন্ত্রণ সিস্টেম বলে মনে হচ্ছে। গিটহাব এবং বিটবকেট ব্যাকআপের জন্য সর্বাধিক জনপ্রিয় হোস্টিং পরিষেবাদি

ভার্চুয়াল এনভায়রনমেন্ট
আমি ভ্যুচুয়ালেনভ এবং ভার্চুয়ালেনভ্রাপার ব্যবহার করি। দ্বিতীয়টি ইনস্টল করার পরে, আপনাকে আপনার কার্যনির্বাহী ডিরেক্টরি সেট আপ করতে হবে। খনিটি আমার / হোম / এনভিএস ডিরেক্টরিতে রয়েছে, কারণ এটি ভার্চুয়ালেনভ্রাপার ইনস্টলেশন গাইডে প্রস্তাবিত। তবে আমি মনে করি না যে সবচেয়ে গুরুত্বপূর্ণ জিনিসটি এটি কোথায় রাখা হয়েছে। ভার্চুয়াল পরিবেশের সাথে কাজ করার সময় সর্বাধিক গুরুত্বপূর্ণ বিষয়টি প্রয়োজনীয়তা.টেক্সট ফাইলকে আপ টু ডেট করে রাখছে।

pip freeze -l > requirements.txt 

স্ট্যাটিক রুট
প্রকল্প ফোল্ডার

মিডিয়া রুট
প্রকল্প ফোল্ডার

পুনরায়
সংগ্রহস্থল রুট পড়ুন

লাইসেন্সের
সংগ্রহস্থল মূল

নথি
সংগ্রহস্থল মূল। এই অজগর প্যাকেজগুলি আপনাকে আপনার ডকুমেন্টেশনগুলিকে সহজতর করতে সহায়তা করতে পারে:

স্কেচ

উদাহরণ

তথ্যশালা


আপনার অভিজ্ঞতার কথা জানানোর জন্য ধন্যবাদ। আপনার কাঠামোতে প্রচুর 'প্রকল্প *' ডিরেক্টরি রয়েছে। আপনি সম্ভবত বাস্তব জীবনে এই জাতীয় নাম ব্যবহার করবেন না, তাই না? ধরা যাক আমাদের একটি 'টোডো' প্রকল্প আছে। এই ক্ষেত্রে এই ডায়ারের নাম আপনি কীভাবে রাখবেন? আপনার বর্তমান কাঠামোটিতে আমি যে সমস্যাটি দেখতে পাচ্ছি তা হ'ল সংগ্রহস্থলগুলি অ-সংগ্রহস্থল ফাইলগুলির সাথে মিশ্রণ করছে (আপনি উপরে উল্লিখিত হিসাবে)। .Gitignore এ কোনও ট্র্যাস যোগ করা বিরক্তিকর হতে পারে, তাই না? আরেকটি সন্দেহজনক বিষয় হ'ল প্রকল্পটি থেকে এতদূর দূরে থাকছে v এটা বোঝা যায় না? কেন ~ / ডকস, ~ / স্ট্যাটিকস ইত্যাদি তৈরি করবেন না? এমনকি গিট উত্স ফাইলগুলির কাছে বসতে পছন্দ করে।
রেসারের

আমি তাদের নাম দেব: "টুডো_প্রজেক্ট" -> টুডো -> টুডো (বা সম্ভবত টুডাপ)। আমি মনে করি যে এটি ডাইরেক্টেক্টরি হায়ারার্কির মূলের ভাণ্ডার ফোল্ডারে মৌমাছি নেওয়া গুরুত্বপূর্ণ। তবে, কেবল আমার মতামত। পরিবেশ ডিরেক্টরি সম্পর্কে, যখন আপনাকে উত্পাদন পরিবেশ স্থাপন করতে হবে, আপনি কেবল টাইপিং দ্বারা সম্পন্ন করেছেন: পাইপ ইনস্টল করুন-ইউ-আর প্রয়োজনীয়তাগুলি। Txt। তবে, যেমনটি আমি বলেছি, সব কিছুর জন্য একটি সমাধান নেই।
কর

সুতরাং মূল অ্যাপ্লিকেশনটির পথ হ'ল "প্রকল্পগুলি / টু_প্রজেক্ট / টুডো / টোডো"। শব্দ "প্রকল্পগুলি" দুবার পুনরাবৃত্তি হয়েছে, এবং "টুডু" শব্দটি তিনবার পুনরাবৃত্তি হয়েছে। এটি "প্রকল্পগুলি / প্রকল্প / আমার_প্রজেক্ট / প্রকল্প_ডির / প্রকল্প / প্রকল্প" এর মতো বলে মনে হচ্ছে। নামগুলি খুব অস্পষ্ট। এটি আমার ডিরেক্টরি কাঠামোয় সমাধান করার চেষ্টা করছি এমন একটি বড় সমস্যা। শ্রেণিবিন্যাস বুঝতে সহজ করার জন্য আমি ডিরেক্টরিগুলির নাম রাখতে চাই। ভাণ্ডার মূল সম্পর্কে কী, আপনি কেন এটি গুরুত্বপূর্ণ তা দয়া করে ব্যাখ্যা করতে পারেন? এছাড়াও আপনি দয়া করে মূল প্রকল্পের ডিয়ারের বাইরে এনভিএসগুলি রাখার বিষয়ে ভাল কি তা ব্যাখ্যা করতে পারেন?
রেসারে

13

আমি একটি নতুন 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/গিট সাবমডিউলসের জন্য একটি ডিরেক্টরি কিন্তু সাধারণত আমি সেগুলি static/ফোল্ডারে রাখি ।


4

আমি আমার সিস্টেমে যা অনুসরণ করি তা এখানে।

  1. সমস্ত প্রকল্প আছে: একটি হল আমার হোম ফোল্ডারে প্রকল্প ডিরেক্টরির অর্থাত ~/projects। সমস্ত প্রকল্প এটির মধ্যে বিশ্রামে।

  2. স্বতন্ত্র প্রকল্প : আমি পৃথক প্রকল্পের জন্য জ্যাঙ্গো-স্কেল নামে অনেক বিকাশকারী দ্বারা ব্যবহৃত একটি মানক কাঠামো টেম্পলেট অনুসরণ করি । এটি মূলত আপনার সমস্ত স্থিতিশীল ফাইল এবং মিডিয়া ফাইল এবং সকলের যত্ন নেয়।

  3. ভার্চুয়াল পরিবেশ : সিস্টেমের মধ্যে সমস্ত ভার্চুয়াল পরিবেশ সংরক্ষণ করার জন্য আমার বাড়ির অভ্যন্তরে আমার কাছে ভার্চুয়ালেনভস ফোল্ডার রয়েছে~/virtualenvs । এটি আমাকে নমনীয়তা দেয় যা আমি জানি যে সমস্ত ভার্চুয়াল পরিবেশ আমার রয়েছে এবং সহজেই ব্যবহার দেখতে পাবে

উপরের 3 টি আমার কাজের পরিবেশের প্রধান পার্টিশন।

আপনি উল্লিখিত অন্যান্য সমস্ত অংশগুলি বেশিরভাগ প্রকল্পের ভিত্তিতে প্রকল্পের উপর নির্ভরশীল (যেমন আপনি বিভিন্ন প্রকল্পের জন্য বিভিন্ন ডাটাবেস ব্যবহার করতে পারেন)। সুতরাং তাদের পৃথক প্রকল্পগুলিতে থাকা উচিত।


ধন্যবাদ. নন-রেপোজিটরি ফাইলগুলির সাহায্যে সংগ্রহশালার মিশ্রন করার সময় .gitignore এ কোনও ট্র্যাস যোগ করা বিরক্তিকর হতে পারে। তাই না? আমার কিছু প্রকল্পের দশ এবং আরও বেশি ফাইল এবং ডায়ার রয়েছে, সুতরাং এটি আমার জন্য আসল সমস্যা তৈরি করে। আরেকটি সন্দেহজনক বিষয় হ'ল প্রকল্পটি থেকে এতদূর দূরে থাকছে v এই জাতীয় সমাধানে নমনীয়তা কী? কেন ~ / ডকস, ~ / স্ট্যাটিকস ইত্যাদি তৈরি করবেন না? এমনকি গিট উত্স ফাইলগুলির কাছে বসতে পছন্দ করে। আমি ভেবেছি নমনীয়তা হ'ল যখন আমি কেবল কপিরাইট / মুভ / আর্কাইভ / পুরো প্রকল্প ডিরেক্টরিটি ভুচুয়ালেনভ সহ সরিয়ে ফেলতে পারি এবং সহজেই একটি প্রকল্পের মধ্যে একাধিক এনভিকে বজায় রাখতে পারি
রেসারে

4

জাজানো প্রকল্প কঙ্কাল অনুসারে, যথাযথ ডিরেক্টরি কাঠামো অনুসরণ করা যেতে পারে:

[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 সর্বশেষ ডিরেক্টরি গঠন জন্য।


7
আমি [প্রকল্পের নাম] / [প্রকল্পের নাম] পদ্ধতির ঘৃণা করি!)
রেসারের

1
জ্যাঙ্গো-প্রকল্প-কঙ্কাল "জাজানো ডকুমেন্টেশন" নয়। "জাঙ্গো-প্রকল্প-কঙ্কাল অনুসারে, ..." বলা আরও সঠিক হবে accurate
ডেভিড উইনিস্কি

0

আপনি https://github.com/Mischback/django-project-skeleton সংগ্রহশালা ব্যবহার করতে পারেন ।

কমান্ডের নীচে রান করুন:

$ 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
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.