पायथन एप्लिकेशन के लिए सबसे अच्छी परियोजना संरचना क्या है? [बन्द है]

Question

कल्पना करें कि आप पायथन में एक गैर-तुच्छ अंत-उपयोगकर्ता डेस्कटॉप (वेब ​​नहीं) अनुप्रयोग विकसित करना चाहते हैं। प्रोजेक्ट के फ़ोल्डर पदानुक्रम की संरचना करने का सबसे अच्छा तरीका क्या है?

वांछनीय विशेषताएं रखरखाव में आसान हैं, आईडीई-मित्रता, स्रोत नियंत्रण शाखा के लिए उपयुक्तता / विलय, और स्थापित पैकेजों की आसान पीढ़ी।

विशेष रूप से:

1. आप स्रोत कहां से लाते हैं?
2. आपने एप्लिकेशन स्टार्टअप स्क्रिप्ट कहाँ रखी हैं?
3. आप आईडीई प्रोजेक्ट क्रॉफ्ट कहां लगाते हैं?
4. आप इकाई / स्वीकृति परीक्षण कहाँ लगाते हैं?
5. आप गैर-पायथन डेटा को कहां से कॉन्फ़िगर करते हैं जैसे कि कॉन्फिग फाइल?
6. आप गैर-पायथन स्रोतों जैसे कि C ++ के लिए pyd / so बाइनरी एक्सटेंशन मॉड्यूल कैसे डालते हैं?

Answer 1

बहुत ज्यादा मामला नहीं है। जो भी आपको खुश करेगा वह काम करेगा। बहुत सारे मूर्खतापूर्ण नियम नहीं हैं क्योंकि पायथन परियोजनाएं सरल हो सकती हैं।

• /scriptsया /binउस तरह के कमांड-लाइन इंटरफ़ेस सामान के लिए
• /tests अपने परीक्षणों के लिए
• /lib आपकी सी-भाषा पुस्तकालयों के लिए
• /doc अधिकांश प्रलेखन के लिए
• /apidoc एपीडोक जनित एपीआई डॉक्स के लिए।

और शीर्ष-स्तरीय निर्देशिका में README, कॉन्फ़िग और व्हाट्सएप शामिल हो सकते हैं।

एक /srcपेड़ का उपयोग करना या न करना मुश्किल विकल्प है । अजगर के बीच एक अंतर नहीं है /src, /libहै, और /binजावा या सी की तरह है।

चूंकि शीर्ष-स्तरीय /srcनिर्देशिका को कुछ लोगों द्वारा अर्थहीन के रूप में देखा जाता है, इसलिए आपकी शीर्ष-स्तरीय निर्देशिका आपके एप्लिकेशन की शीर्ष-स्तरीय वास्तुकला हो सकती है।

• /foo
• /bar
• /baz

मैं "नाम-के-मेरे-उत्पाद" निर्देशिका के तहत यह सब डालने की सलाह देता हूं। इसलिए, यदि आप किसी एप्लिकेशन का नाम लिख रहे हैं, तो quuxजिस निर्देशिका में यह सब है, उसका नाम है /quux।

एक अन्य परियोजना PYTHONPATH, तब, मॉड्यूल /path/to/quux/fooका पुन: उपयोग करने के लिए शामिल हो सकती है QUUX.foo।

मेरे मामले में, जब से मैं कोमोडो एडिट का उपयोग करता हूं, मेरा आईडीई कॉफ़्ट एक .KPF फ़ाइल है। मैंने वास्तव में इसे शीर्ष-स्तरीय /quuxनिर्देशिका में डाल दिया , और इसे एसवीएन में जोड़ दिया।

Comments

कोई भी खुला स्रोत अजगर परियोजनाएं जो आप उनकी निर्देशिका संरचना का अनुकरण करने की सिफारिश करेंगे?

— लांस रशिंग

एक अच्छे उदाहरण के लिए Django को देखें।

— S.Lott

मैं Django को एक अच्छा उदाहरण नहीं मानता - sys.path के साथ चालें खेलना मेरी किताब में एक त्वरित DQ है।

— चार्ल्स डफी

"ट्रिक्स": Django रूट प्रोजेक्ट फ़ोल्डर के माता-पिता को sys.path में जोड़ता है, ताकि मॉड्यूल को "project.app.module import klass से" या "app.module import klass" से आयात किया जा सके।

— जोनाथन हार्टले

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

— योंगवेई वू

Answer 2

एक अजगर परियोजना के जीन-पॉल काल्डेरोन की फाइलसिस्टम संरचना के अनुसार :

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

Comments

Project/project/? आह, दूसरे का पैकेज नाम।

— सीआईएस टिम्मरमैन

बिन फ़ोल्डर में निष्पादन योग्य फ़ाइल परियोजना मॉड्यूल को कैसे संदर्भित करती है? (मुझे नहीं लगता कि अजगर वाक्यविन्यास ../में एक बयान में अनुमति देता है)

— थोरसुमोनर

@ थोरसुमोनर सरल। आप पैकेज स्थापित करें! ( pip install -e /path/to/Project)

— क्रोल्टन

यह बहुत अच्छा होगा यदि कोई इस लेआउट के नमूने को hello.py और hello-test.py के साथ जोड़ देगा और इसे हमारे लिए नए रूप में उपलब्ध कराएगा।

— जेरेमीजजब्रोएन

@ क्लोक कोर -eध्वज है, जो पैकेज को एक संपादन योग्य पैकेज के रूप में स्थापित करता है, अर्थात, इसे वास्तविक प्रोजेक्ट फ़ोल्डर के लिंक के रूप में स्थापित करता है। निष्पादन योग्य तब केवल import projectमॉड्यूल तक पहुंच हो सकता है।

— क्रोल्टन

Answer 3

जीन-पॉल काल्डेरोन का यह ब्लॉग पोस्ट आमतौर पर Freenode पर #python में एक उत्तर के रूप में दिया गया है।

पायथन परियोजना की फाइलसिस्टम संरचना

करना:

• निर्देशिका को आपके प्रोजेक्ट से संबंधित कुछ नाम दें। उदाहरण के लिए, यदि आपकी परियोजना को "मुड़" नाम दिया गया है, तो उसके स्रोत फ़ाइलों के लिए शीर्ष-स्तरीय निर्देशिका को नाम दें Twisted। जब आप रिलीज़ करते हैं, तो आपको एक संस्करण संख्या प्रत्यय शामिल करना चाहिए Twisted-2.5:।
• एक निर्देशिका बनाएं Twisted/binऔर अपने निष्पादक को वहां रखें, यदि आपके पास कोई है। उन्हें .pyविस्तार न दें , भले ही वे पायथन स्रोत की फाइलें हों। अपने प्रोजेक्ट में कहीं और परिभाषित एक मुख्य फ़ंक्शन के आयात और कॉल को छोड़कर उनमें कोई कोड न डालें। (थोड़ा शिकन: चूंकि विंडोज पर, फ़ाइल एक्सटेंशन द्वारा दुभाषिया का चयन किया जाता है, आपके विंडोज उपयोगकर्ता वास्तव में .py एक्सटेंशन चाहते हैं। इसलिए, जब आप विंडोज के लिए पैकेज करते हैं, तो आप इसे जोड़ना चाह सकते हैं। दुर्भाग्य से कोई आसान डिस्टिलिट ट्रिक नहीं है। मैं इस प्रक्रिया को स्वचालित करना जानता हूं। यह मानते हुए कि POSIX पर .py एक्सटेंशन केवल एक मस्सा है, जबकि विंडोज पर यह कमी एक वास्तविक बग है, यदि आपके उपयोगकर्ताबेस में विंडोज उपयोगकर्ता शामिल हैं, तो आप सिर्फ .py का विकल्प चुन सकते हैं। हर जगह विस्तार।)
• यदि आपकी परियोजना एकल पायथन स्रोत फ़ाइल के रूप में अभिव्यक्त होती है, तो इसे निर्देशिका में रखें और इसे अपनी परियोजना से संबंधित कुछ नाम दें। उदाहरण के लिए, Twisted/twisted.py। यदि आपको कई स्रोत फ़ाइलों की आवश्यकता है, तो इसके बजाय ( Twisted/twisted/, खाली के साथ Twisted/twisted/__init__.py) एक पैकेज बनाएं और उसमें अपने स्रोत फ़ाइलों को रखें। उदाहरण के लिए, Twisted/twisted/internet.py।
• अपने यूनिट परीक्षणों को अपने पैकेज के उप-पैकेज में रखें (नोट - इसका मतलब है कि ऊपर एकल पायथन स्रोत फ़ाइल विकल्प एक ट्रिक था - आपको हमेशा अपने यूनिट परीक्षणों के लिए कम से कम एक अन्य फ़ाइल की आवश्यकता होती है)। उदाहरण के लिए, Twisted/twisted/test/। बेशक, इसके साथ एक पैकेज बनाएं Twisted/twisted/test/__init__.py। फ़ाइलों की तरह परीक्षण रखें Twisted/twisted/test/test_internet.py।
• यदि आप अच्छा महसूस कर रहे हैं तो क्रमशः अपने सॉफ़्टवेयर को जोड़ें Twisted/READMEऔर Twisted/setup.pyसमझाएं और स्थापित करें।

मत करो:

• अपने स्रोत को किसी निर्देशिका में रखें srcया कहा जाता है lib। यह स्थापित किए बिना चलाने के लिए कठिन बनाता है।
• अपने परीक्षणों को अपने पायथन पैकेज के बाहर रखें। यह स्थापित संस्करण के खिलाफ परीक्षण चलाने के लिए कठिन बनाता है।
• एक पैकेज बनाएं जिसमें केवल एक है __init__.pyऔर फिर अपना सभी कोड डालें __init__.py। पैकेज के बजाय केवल एक मॉड्यूल बनाएं, यह सरल है।
• पायथन को अपने मॉड्यूल या पैकेज को आयात करने में सक्षम बनाने के लिए जादुई हैक के साथ आने की कोशिश करें, उपयोगकर्ता को अपने आयात पथ में निर्देशिका को जोड़ने के बिना (या तो PYTHONPATH या किसी अन्य तंत्र के माध्यम से)। जब आपके सॉफ़्टवेयर उनके वातावरण में काम नहीं करते हैं, तो आप सभी मामलों को सही ढंग से संभाल नहीं पाएंगे और उपयोगकर्ता आपसे नाराज हो जाएंगे।

Comments

यह वही था जो मुझे चाहिए था। "पाइथन को अपने मॉड्यूल या पैकेज को आयात करने में सक्षम बनाने के लिए जादुई हैक्स के साथ आने की कोशिश न करें, ताकि उपयोगकर्ता निर्देशिका को अपने आयात पथ में शामिल किए बिना कर सकें।" जानकार अच्छा लगा!

— जैक ओ'कॉनर

बात यह है, यह एक परियोजना के महत्वपूर्ण डॉक्टर भाग का उल्लेख नहीं करता है जहां इसे रखना है।

— lpapp

"स्रोत को src या lib नामक निर्देशिका में रखें। यह बिना इंस्टॉलेशन के चलाने में कठिन बनाता है।" क्या स्थापित किया जाएगा? क्या यह dir नाम है जो इस मुद्दे का कारण बनता है, या तथ्य यह है कि यह सबडिर है?

— पीटर एर्लिच

"कुछ लोग दावा करेंगे कि आपको अपने मॉड्यूल के भीतर अपने परीक्षणों को वितरित करना चाहिए - मैं असहमत हूं। यह अक्सर आपके उपयोगकर्ताओं के लिए जटिलता बढ़ाता है; कई परीक्षण सूटों में अक्सर अतिरिक्त निर्भरता और रनटाइम संदर्भों की आवश्यकता होती है।" python-guide-pt-br.readthedocs.io/en/latest/writing/structure/…

— endolith

"यह स्थापित किए बिना चलाने के लिए कठिन बनाता है।" - यह बात है

— निक टी।

Answer 4

चेक आउट ओपन सोर्सिंग एक पायथन प्रोजेक्ट द राइट वे ।

मुझे उस उत्कृष्ट लेख के प्रोजेक्ट लेआउट भाग का उद्धरण दें :

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

सबसे ऊपर शुरू करते हैं। अधिकांश परियोजनाओं में कई शीर्ष स्तर की फाइलें होती हैं (जैसे setup.py, README.md, आवश्यकताएँ.txt, आदि)। फिर तीन निर्देशिकाएं होती हैं जो हर परियोजना में होनी चाहिए:

• डॉक्स डायरेक्टरी जिसमें प्रोजेक्ट डॉक्यूमेंटेशन हो
• एक निर्देशिका प्रोजेक्ट के नाम के साथ नामित होती है जो वास्तविक पायथन पैकेज को संग्रहीत करती है
• दो स्थानों में से एक में एक परीक्षण निर्देशिका
  • परीक्षण कोड और संसाधनों से युक्त पैकेज निर्देशिका के अंतर्गत
  • एक स्टैंड-अलोन शीर्ष स्तर निर्देशिका के रूप में आपकी फ़ाइलों को कैसे व्यवस्थित किया जाना चाहिए, इसकी बेहतर समझ पाने के लिए, यहां मेरी एक परियोजना के लिए लेआउट का सरलीकृत स्नैपशॉट है, सैंडमैन:

$ pwd
~/code/sandman
$ tree
.
|- LICENSE
|- README.md
|- TODO.md
|- docs
|   |-- conf.py
|   |-- generated
|   |-- index.rst
|   |-- installation.rst
|   |-- modules.rst
|   |-- quickstart.rst
|   |-- sandman.rst
|- requirements.txt
|- sandman
|   |-- __init__.py
|   |-- exception.py
|   |-- model.py
|   |-- sandman.py
|   |-- test
|       |-- models.py
|       |-- test_sandman.py
|- setup.py

जैसा कि आप देख सकते हैं, कुछ शीर्ष स्तर की फाइलें हैं, डॉक्स निर्देशिका (उत्पन्न एक खाली निर्देशिका है जहां स्फिंक्स उत्पन्न दस्तावेज डाल देगा), एक सैंडमैन निर्देशिका, और सैंडमैन के तहत एक परीक्षण निर्देशिका।

Comments

मैं ऐसा करता हूं, लेकिन इससे भी अधिक: मेरे पास एक 'env' लक्ष्य के साथ एक टॉपवेल मेकफाइल है जो 'virtualenbv env' को स्वचालित करता है; ./env/bin/pip स्थापित -r आवश्यकताएँ। ./env/bin/python setup.py विकसित होगा, और आमतौर पर एक 'परीक्षण' लक्ष्य भी होता है जो env पर निर्भर करता है और परीक्षण निर्भरता भी स्थापित करता है और फिर py.test चलाता है।

— पीजेड

क्या आप अपने विचार का विस्तार कर सकते हैं? क्या आप Makefileउसी स्तर पर रखने की बात कर रहे हैं setup.py? इसलिए अगर मैं समझता हूं कि आप सही ढंग से make envएक नया निर्माण कर रहे हैं venvऔर उसमें पैकेज स्थापित कर रहे हैं ...?

— सेंटऑनारियो

@ सेंटऑनारियो बिल्कुल। जैसा कि उल्लेख किया गया है कि मेरे पास परीक्षण चलाने के लिए आम तौर पर एक 'परीक्षण' लक्ष्य होता है, और कभी-कभी एक 'रिलीज़' लक्ष्य जो वर्तमान टैग को देखता है और एक पहिया बनाता है और इसे pypi को भेजता है।

— pjz

Answer 5

"पायथन पैकेजिंग अथॉरिटी" का एक नमूना है:

https://github.com/pypa/sampleproject

यह एक नमूना परियोजना है जो पैकेजिंग और वितरण परियोजनाओं पर पायथन पैकेजिंग उपयोगकर्ता गाइड के ट्यूटोरियल की सहायता के रूप में मौजूद है।

Comments

+ root/src/*संरचना की ओर रुझान : github.com/pypa/sampleproject/commit/…

— qrtLs

प्रोजेक्ट संरचना पाठ के लिए

— qrtLs

Answer 6

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

• आप स्रोत कहां से लाते हैं?

  • शालीनता से बड़ी परियोजनाओं के लिए यह स्रोत को कई अंडों में विभाजित करने के लिए समझ में आता है। प्रत्येक अंडा एक अलग सेप्टुपूल-लेआउट के रूप में जाएगा PROJECT_ROOT/src/<egg_name>।

• आपने एप्लिकेशन स्टार्टअप स्क्रिप्ट कहाँ रखी हैं?

  • आदर्श विकल्प यह है कि एप्लिकेशन स्टार्टअप स्क्रिप्ट entry_pointको अंडों में से एक के रूप में पंजीकृत किया जाए ।

• आप आईडीई प्रोजेक्ट क्रॉफ्ट कहां लगाते हैं?

  • आईडीई पर निर्भर करता है। उनमें से कई PROJECT_ROOT/.<something>परियोजना की जड़ में अपना सामान रखते हैं , और यह ठीक है।

• आप इकाई / स्वीकृति परीक्षण कहाँ लगाते हैं?

  • प्रत्येक अंडे में परीक्षणों का एक अलग सेट होता है, जिसे उसकी PROJECT_ROOT/src/<egg_name>/testsनिर्देशिका में रखा जाता है । मैं व्यक्तिगत रूप py.testसे उन्हें चलाने के लिए उपयोग करना पसंद करता हूं।

• आप गैर-पायथन डेटा को कहां से कॉन्फ़िगर करते हैं जैसे कि कॉन्फिग फाइल?

  • निर्भर करता है। गैर-पायथन डेटा के विभिन्न प्रकार हो सकते हैं।
    • "संसाधन" , यानी डेटा जिसे एक अंडे के भीतर पैक किया जाना चाहिए। यह डेटा पैकेज नेमस्पेस के भीतर कहीं, संबंधित अंडे निर्देशिका में चला जाता है। इसका उपयोग मानक लाइब्रेरी से मॉड्यूल के माध्यम से या पायथन 3.7 के बाद pkg_resourcesसे पैकेज के माध्यम से किया जा सकता है ।setuptoolsimportlib.resources
    • "कॉन्फिग-फाइल्स" , अर्थात नॉन-पायथन फाइल्स जिन्हें प्रोजेक्ट सोर्स फाइल्स के लिए बाहरी माना जाता है, लेकिन जब एप्लिकेशन चलना शुरू होता है तो कुछ वैल्यूज़ के साथ इनिशियलाइज़ करना पड़ता है। विकास के दौरान मैं ऐसी फाइलों को रखना पसंद करता हूं PROJECT_ROOT/config। तैनाती के लिए विभिन्न विकल्प हो सकते हैं। विंडोज़ पर उपयोग कर सकते हैं %APP_DATA%/<app-name>/configलिनक्स पर,, /etc/<app-name>या /opt/<app-name>/config।
    • जनरेट की गई फाइलें , यानी फाइलें, जिन्हें निष्पादन के दौरान एप्लिकेशन द्वारा बनाया या संशोधित किया जा सकता है। मैं उन्हें PROJECT_ROOT/varविकास के /varदौरान और लिनक्स तैनाती के दौरान रखना पसंद करूंगा ।
• आप गैर-पायथन स्रोतों जैसे कि C ++ के लिए pyd / so बाइनरी एक्सटेंशन मॉड्यूल कैसे डालते हैं?
  • में PROJECT_ROOT/src/<egg_name>/native

दस्तावेज़ीकरण आम तौर पर PROJECT_ROOT/docया में जाएगा PROJECT_ROOT/src/<egg_name>/doc(यह इस बात पर निर्भर करता है कि क्या आप कुछ अंडों को एक अलग बड़ी परियोजना मानते हैं)। कुछ अतिरिक्त विन्यास जैसे PROJECT_ROOT/buildout.cfgऔर फाइलों में होगा PROJECT_ROOT/setup.cfg।

Comments

एक महान जवाब के लिए धन्यवाद! आपने मेरे लिए कई बातें स्पष्ट कीं! मेरा बस एक ही सवाल है: क्या अंडों से घोंसला बन सकता है?

— शौकी

नहीं, आप स्टोर करने के अर्थ में "घोंसला" अंडे नहीं दे सकते हैं। अन्य फ़ाइलों के भीतर .gg फ़ाइलों और उम्मीद है कि यह बहुत उपयोग होगा [जब तक आप वास्तव में कुछ अजीब नहीं हैं]। हालाँकि, आप "वर्चुअल" अंडे बना सकते हैं - खाली पैकेज जो कोई उपयोगी कोड प्रदान नहीं करते हैं, लेकिन उनकी निर्भरता सूची में अन्य पैकेजों को सूचीबद्ध करते हैं। इस तरह, जब कोई उपयोगकर्ता इस तरह के पैकेज को स्थापित करने का प्रयास करता है, तो वह कई आश्रित अंडे को पुन: स्थापित करेगा।

— केटी।

@ के बारे में आप थोड़ा विस्तार से बता सकते हैं कि आप उत्पन्न डेटा को कैसे संभालते हैं? विशेष रूप से, आप (कोड में) विकास और तैनाती के बीच अंतर कैसे करते हैं? मुझे लगता है कि आपके पास कुछ base_data_locationचर है, लेकिन आप इसे उचित तरीके से कैसे सेट करते हैं?

— सेमीप्रिंट

मुझे लगता है कि आप "रनटाइम डेटा" के बारे में बोल रहे हैं - कुछ लोग अक्सर / var / packagename या ~ / .packagename / var, या whatnot के तहत डालते हैं। अधिकांश समय वे विकल्प डिफ़ॉल्ट के रूप में पर्याप्त होते हैं जिन्हें आपके उपयोगकर्ता बदलने की परवाह नहीं करते हैं। यदि आप इस व्यवहार को देखते रहने की अनुमति देना चाहते हैं, तो विकल्प प्रचुर मात्रा में हैं और मुझे नहीं लगता कि एक भी फिट-ऑल बेस्ट अभ्यास है। विशिष्ट विकल्प: a) ~ / .packagename / configfile, b) उन का संयोजन MY_PACKAGE_CONFIG = / path / to / configfile c) कमांड-लाइन विकल्प या फ़ंक्शन पैरामीटर्स d) का संयोजन।

— केटी।

ध्यान दें कि कहीं न कहीं एक सिंगलटन कॉन्फिगर क्लास होना काफी सामान्य है, जो आपके लिए आपके पसंदीदा कॉन्फिग लोडिंग लॉजिक को हैंडल करता है और शायद उपयोगकर्ता को रनटाइम में सेटिंग्स को संशोधित करने की सुविधा भी देता है। सामान्य तौर पर, हालांकि, मुझे लगता है कि यह एक अलग सवाल के लायक एक मुद्दा है (जो यहां कहीं से पहले पूछा गया हो सकता है)।

— केटी।

Answer 7

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

जहां तक ​​विस्तार के स्रोतों की बात है, हमारे पास ट्रंक के तहत एक कोड निर्देशिका है जिसमें अजगर के लिए एक निर्देशिका और विभिन्न अन्य भाषाओं के लिए एक निर्देशिका शामिल है। व्यक्तिगत रूप से, मैं अगली बार किसी भी एक्सटेंशन कोड को अपने स्वयं के भंडार में डालने की कोशिश कर रहा हूं।

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

Comments

हां। मैं इसके बारे में "पायथोनिक" बनने की कोशिश करता हूं: स्पष्ट रूप से निहित से बेहतर है .. निर्देशिका उत्तराधिकारियों को पढ़ा / लिखा जाने से अधिक निरीक्षण किया जाता है। आदि ..

— eric

Answer 8

गैर-अजगर डेटा को सेटपूलpackage_data में समर्थन का उपयोग करके अपने पायथन मॉड्यूल के अंदर सबसे अच्छा बंडल किया जाता है । एक चीज जो मैं दृढ़ता से सुझाता हूं, वह साझा नामस्थान बनाने के लिए नेमस्पेस पैकेज का उपयोग कर रहा है, जिसे कई परियोजनाएं उपयोग कर सकती हैं - बहुत कुछ जैसे कि com.yourcompany.yourproject(और एक साझा com.yourcompany.utilsनाम स्थान रखने में सक्षम होने के लिए जावा कन्वेंशन )।

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

यहां कुछ अन्य उत्तरों के विपरीत, मैं एक srcनिर्देशिका शीर्ष-स्तर (साथ docऔर testनिर्देशिका) के साथ होने पर +1 हूं । प्रलेखन निर्देशिका पेड़ों के लिए विशिष्ट सम्मेलनों आप क्या उपयोग कर रहे हैं पर निर्भर करता है; उदाहरण के लिए, स्फिंक्स के पास अपने स्वयं के कन्वेंशन हैं जो इसके क्विकस्टार्ट टूल का समर्थन करता है।

कृपया, सेटपूल और pkg_resources का लाभ उठाएं; यह अन्य परियोजनाओं के लिए आपके कोड के विशिष्ट संस्करणों पर भरोसा करना आसान बनाता है (और यदि आप उपयोग कर रहे हैं तो कई संस्करणों के लिए अलग-अलग गैर-कोड फ़ाइलों के साथ स्थापित होने के लिए package_data)।