|
1 | 1 | .. role:: emoji-size |
2 | 2 |
|
3 | 3 | .. meta:: |
4 | | - :description: کتاب آنلاین و آزاد آموزش زبان برنامهنویسی پایتون به فارسی - درس سوم ایجاد و اجرای پروژه از پایتون |
| 4 | + :description: پایتون به فارسی - کتاب آنلاین و آزاد آموزش زبان برنامهنویسی پایتون - درس سوم: چگونگی ایجاد و اجرای یک پروژه پایتون |
5 | 5 | :keywords: پایتون,آموزش پایتون, آموزش برنامه نویسی, ایجاد پروژه پایتون, اسکریپت پایتون, ماژول پایتون, بسته پایتون, ساختار پایتون, پروژه پایتون, سورس کد, سورس کد پایتون, اجرای پایتون, اسکریپت, ماژول, pyvenv, virtualenv |
6 | 6 |
|
7 | 7 |
|
| 8 | +.. _lesson-03: |
| 9 | + |
8 | 10 | درس ۰۳: چگونگی ایجاد و اجرای یک پروژه پایتون |
9 | 11 | ============================================= |
10 | 12 |
|
|
27 | 29 |
|
28 | 30 | ---- |
29 | 31 |
|
| 32 | +.. _project-structure: |
| 33 | + |
30 | 34 | ساختار پروژه |
31 | 35 | -------------- |
32 | | -نخستین گام در توسعه یک برنامه پایتون ایجاد یک پروژه است که پس از آن نوشتن کدها یا ایجاد سورس کد (`Source code <https://en.wikipedia.org/wiki/Source_code>`_) برنامه آغاز میشود. |
33 | 36 |
|
34 | 37 | سورس کد یک پروژه به زبان پایتون در قالب یک یا چند «ماژول» (Module) توسعه مییابد که در سورس کدهایی با بیش از یک ماژول بهتر است ماژولهایی که از نظر منطقی با یکدیگر مرتبط هستند را درون دایرکتوریهایی مجزا قرار دهیم که به این نوع دایرکتوریها در زبان پایتون «بسته» (Package) گفته میشود. |
35 | 38 |
|
36 | 39 | .. tip:: |
37 | 40 | یک یا چند ماژول درون یک دایرکتوری مشخص تشکیل یک بسته را میدهند و هر بسته خود میتواند حاوی بسته(های) دیگری باشد. |
38 | 41 |
|
39 | 42 | .. note:: |
40 | | - از نسخه 3.3 پایتون با افزوده شدن ویژگی جدیدی به نام «بسته فضانام» (Namespace Package - `PEP 420 <http://www.python.org/dev/peps/pep-0420>`_)، تعریف بسته پایتون به دو شاخه «بسته عادی» (Regular Package) که همان تعریف قدیمی از بسته میباشد و بسته فضانام گسترش یافته است. [در درس مربوط به ماژولها بیشتر توضیح داده خواهد شد] |
| 43 | + از نسخه 3.3 پایتون با افزوده شدن ویژگی جدیدی به نام «بسته فضانام» (Namespace Package - `PEP 420 <http://www.python.org/dev/peps/pep-0420>`_)، تعریف بسته پایتون به دو شاخه «بسته عادی» (Regular Package) که همان تعریف قدیمی از بسته میباشد و بسته فضانام گسترش یافته است. در انتهای این درس به تفاوت این دو بسته پرداخته خواهد شد. |
41 | 44 |
|
42 | 45 | در تعریف زبان پایتون دو نوع ماژول وجود دارد: |
43 | 46 |
|
44 | | -۱- Pure Module (ماژول ناب)، همان تعریف عادی از ماژول پایتون است؛ فایلهایی با پسوند py که کد (تعاریف و دستورات) پایتون در آنها نوشته میشوند. |
| 47 | +۱- Pure Module (ماژول عادی)، همان تعریف عادی از ماژول پایتون است؛ فایلهایی با پسوند py که کد (تعاریف و دستورات) پایتون در آنها نوشته میشوند. |
45 | 48 |
|
46 | | -۲- Extension Module (ماژول توسعه)، ماژولهایی که توسط زبانهای برنامهنویسی دیگری به غیر از پایتون ایجاد شدهاند. از درس یکم به خاطر داریم که پایتون یک زبان توسعهپذیر است و در کنار آن میتوان از کدهای نوشته شده با دیگر زبانهای برنامهنویسی استفاده نمود: به مانند C و ++C در پیادهسازی CPython یا Java در پیادهسازی Jython یا #C در پیادهسازی IronPython - [ایجاد و استفاده از این نوع ماژول در درسی جداگانه بررسی خواهد شد.] |
| 49 | +۲- Extension Module (ماژول توسعه)، ماژولهایی که توسط زبانهای برنامهنویسی دیگری به غیر از پایتون ایجاد شدهاند. از درس یکم به خاطر داریم که پایتون یک زبان توسعهپذیر است و در کنار آن میتوان از کدهای نوشته شده با دیگر زبانهای برنامهنویسی استفاده نمود: به مانند C و ++C در پیادهسازی CPython یا Java در پیادهسازی Jython یا #C در پیادهسازی IronPython - بررسی این نوع ماژول خارج از حوزه این کتاب است. در صورت علاقه برای مطالعه بیشتر میتوانید به مستندات پایتون مراجعه (`Python/C API Reference <https://docs.python.org/3/c-api/index.html>`_) یا کتاب Python 3.6 Extending and Embedding Python نوشته Guido Van Rossum را تهیه نمایید. |
47 | 50 |
|
48 | 51 | .. note:: |
49 | | - از این پس هر جایی از کتاب که گفته شود «ماژول» منظور Pure Module خواهد بود، مگر اینکه نام «ماژول توسعه» به صراحت ذکر گردد. |
| 52 | + از این پس هر جایی از این کتاب که گفته شود «ماژول» منظور Pure Module خواهد بود، مگر اینکه نام «ماژول توسعه» به صراحت ذکر گردد. |
50 | 53 |
|
51 | 54 | در ایجاد یک پروژه از پایتون هیچ اجباری به رعایت ساختار خاصی نیست و حتی سورس کد یک پروژه میتواند تنها شامل یک ماژول باشد. به عنوان نمونه، شمای پایین از پروژه فرضی SampleProject را در نظر بگیرید: |
52 | 55 |
|
|
62 | 65 | └── module_three.py |
63 | 66 |
|
64 | 67 | .. tip:: |
65 | | - در پایتون هر بسته (عادی) میبایست حاوی فایل ویژه init\_\_.py_\_\ باشد که البته الزامی به کدنویسی درون این فایل وجود ندارد. این فایل دایرکتوری خود را به عنوان یک بسته (محلی برای یافتن ماژولها) به مفسر پایتون معرفی میکند. |
| 68 | + در پایتون هر **بسته عادی** میبایست حاوی فایل ویژه init\_\_.py_\_\ باشد که البته الزامی به کدنویسی درون این فایل وجود ندارد. این فایل دایرکتوری خود را به عنوان یک بسته (محلی برای یافتن ماژولهای مرتبط) به مفسر پایتون معرفی میکند. |
66 | 69 |
|
67 | 70 | در ایجاد سورس کد باید به صورتی عمل شود که با اجرای یک ماژول مشخص تمام برنامه اجرا گردد. این ماژول معمولا هم نام پروژه در نظر گرفته و با عنوان «اسکریپت» (Script) از آن یاد میشود (اینجا: sample_project.py). در واقع اسکریپت، ماژولی است که با هدف اجرای برنامه توسعه مییابد و ایجاد سورس کد نیز از آن شروع میگردد. از طرفی همانطور که میدانیم یکی از ویژگیهای پایتون امکان برنامه نویسی ماژولار (`Modular <http://en.wikipedia.org/wiki/Modular_programming>`_) است به این صورت که میتوان کدهای خود را بر حسب نیاز در ماژولهایی جداگانه نوشت و با وارد کردن (Import) آنها در اسکریپت (یا ماژولهای دیگر) از کد درون آنها استفاده نمود. با این منطق میشود سورس کد یک پروژه از پایتون را تنها شامل یک اسکریپت تصور کرد که میتواند توسط تعدادی ماژول گسترش یابد؛ البته ممکن است ماژولها نیز بر حسب نیاز در بستههایی جداگانه قرار گرفته باشند. |
68 | 71 |
|
69 | 72 | .. tip:: |
70 | 73 | [`PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_]: در نامگذاری ماژولها تنها از حروف کوچک استفاده میشود و در صورت نیاز میتوان از کاراکتر خط زیرین (``_``) نیز استفاده نمود. نام بستهها کوتاه بوده و از حروف کوچک تشکیل میگردد؛ استفاده از ``_`` در نام بسته پیشنهاد نمیشود. |
71 | 74 |
|
72 | | -اکنون اطلاعات کافی برای شروع یک پروژه از پایتون را دارید ولی چنانچه میخواهید با ساختار مناسب پروژهای که قرار است برای استفاده افراد دیگر از طریق PyPI یا سرویسهایی نظیر github.com منتشر شود (مانند یک کتابخانه کاربردی) آشنا شوید، ادامه این بخش را نیز مطالعه نمایید. در غیر این صورت میتوانید به بخش بعدی از همین درس `پرش <#id7>`_ نمایید. |
| 75 | +اکنون اطلاعات کافی برای شروع یک پروژه از پایتون را دارید ولی چنانچه میخواهید با ساختار مناسب پروژهای که قرار است برای استفاده افراد دیگر از طریق PyPI یا سرویسهایی نظیر github.com منتشر شود (مانند یک کتابخانه کاربردی) آشنا شوید، ادامه این بخش را نیز مطالعه نمایید. در غیر این صورت میتوانید به بخش بعدی از همین درس `پرش <#source-code>`_ نمایید. |
73 | 76 |
|
74 | 77 | جدا از سورس کد لازم است موارد دیگری نیز در ساختار این نوع پروژهها در نظر گرفته شود؛ به ساختار پایین توجه نمایید: |
75 | 78 |
|
76 | 79 |
|
77 | 80 | .. code:: |
78 | 81 | |
79 | | - SampleProject |
| 82 | + my_project |
80 | 83 | . |
81 | | - ├── docs/ |
| 84 | + ├── pyproject.toml |
| 85 | + │ |
82 | 86 | ├── LICENSE.txt |
83 | | - ├── MANIFEST.in |
84 | 87 | ├── README.rst |
85 | 88 | ├── requirements.txt |
86 | | - ├── sampleproject/ |
87 | | - │ ├── __init__.py |
88 | | - │ ├── module_one.py |
89 | | - │ ├── pakage/ |
90 | | - │ │ ├── __init__.py |
91 | | - │ │ ├── module_two.py |
92 | | - │ │ └── module_three.py |
93 | | - │ ├── sample_project.py |
94 | | - │ └── test/ |
95 | | - ├── setup.cfg |
96 | | - └── setup.py |
97 | | -
|
98 | | -ساختار ابتدایی تنها شامل سورس کد میبود ولی در این ساختار تمام سورس کد در قالب یک بسته پایتون بخشی از مجموعه بزرگتری است که در آن یک سری فایل به مانند requirements.txt ،README.rst و setup.py به همراه دو دایرکتوری docs و test افزوده شده است. |
99 | | -در ادامه کمی از کاربرد این موارد توضیح داده میشود ولی تاکید میشود که در حال حاضر نیازی به رعایت این ساختار نیست و در انتهای کتاب با ایجاد یک پروژه عملی و قرار دادن آن بر روی github.com و PyPI به صورت کاربردی با آنها آشنا خواهید شد. [برای کسب اطلاعات بیشتر میتوانید از `اسناد پایتون <http://packaging.python.org/en/latest/distributing.html>`_ استفاده نمایید] |
100 | | - |
101 | | -**setup.py**: این فایل مهم دو کارکرد دارد: |
102 | | -۱- پیکربندی پروژه که از طریق آرگومانهای تابع آماده ``()setup`` درون این فایل صورت میپذیرد. |
103 | | -۲- یک رابط خط فرمان برای اجرای دستورات کاربردی مرتبط با پروژه (الگویی مشابه: ``<python setup.py <commands``). |
104 | | - |
105 | | - فهرست این دستورات از طریق وارد کردن دستوری مشابه ``python setup.py --help-commands`` قابل مشاهده است. |
106 | | - |
107 | | -**setup.cfg**: ساختاری شبیه به یک `فایل ini <http://en.wikipedia.org/wiki/INI_file>`_ داشته و در صورت نیاز گزینههای مربوط به دستورات خط فرمان setup.py در این فایل تعریف میگردند. برای مشاهده فهرست گزینههای یک دستور مشخص میتوانید از الگوی ``<python setup.py --help <commands`` پیروی نمایید. |
108 | | - |
109 | | -**README.rst**: تمام پروژهها میبایست شامل سندی برای توصیف خود باشند. در پایتون برای ایجاد اسناد معمولا از زبان نشانهگذاری `reStructuredText <http://en.wikipedia.org/wiki/ReStructuredText>`_ استفاده میگردد و به همین دلیل این اسناد پسوند rst دارند که البته اجباری به این مورد نیست و میتوانید برای ایجاد این فایل از `Markdown <http://en.wikipedia.org/wiki/Markdown>`_ (پسوند md) نیز استفاده نمایید. |
110 | | - |
111 | | -**MANIFEST.in**: معمولا از این فایل برای معرفی فایلهای غیر پایتونی موجود در پروژه استفاده میشود. زمانی که قصد ایجاد «سورس توزیع» یا sdist از پروژه را داشته باشید (دستوری مشابه: ``python setup.py sdist``) تنها `فایلهای مشخصی <http://docs.python.org/3.4/distutils/sourcedist.html#specifying-the-files-to-distribute>`_ از پروژه شناسایی میشوند و شناساندن باقی فایلها (در صورت وجود) میبایست توسط این فایل (البته با `الگویی خاص <http://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template>`_) انجام گیرد. |
| 89 | + │ |
| 90 | + ├── src/ |
| 91 | + │ └── unique_pakage_name/ |
| 92 | + │ ├── __init__.py |
| 93 | + │ └── main.py |
| 94 | + │ |
| 95 | + ├── docs/ |
| 96 | + └── test/ |
112 | 97 |
|
113 | | -**requirements.txt**: از این فایل برای معرفی کتابخانههای خاصی که در پروژه استفاده شدهاند و در زمان نصب یا اجرای سورس کد، وجود یا نصب بودن آنها نیز ضروری است، استفاده میگردد. |
114 | 98 |
|
115 | | -**LICENSE.txt**: این فایل پروانه انتشار پروژه را شامل میشود و اغلب حاوی یک کپی از متن پروانههای متن باز رایج به مانند `MIT <http://opensource.org/licenses/MIT>`_ ،`GPL <http://opensource.org/licenses/GPL-3.0>`_ یا `BSD <http://opensource.org/licenses/BSD-3-Clause>`_ میباشد. |
| 99 | +ساختار ابتدایی تنها شامل سورس کد میبود ولی در این ساختار تمام سورس کد در قالب یک بسته پایتون بخشی از مجموعه بزرگتری است که در آن یک سری فایل به مانند requirements.txt ،README.rst و pyproject.toml افزوده شده است. تاکید میشود که در حال حاضر نیازی به رعایت این ساختار و ایجاد تمامی این فایلها نیست. |
116 | 100 |
|
117 | | -.. note:: |
118 | | - لازم است تمامی فایلهای یاد شده و دایرکتوری docs در بالاترین شاخه از دایرکتوری پروژه قرار داده شوند. |
| 101 | +اکنون می توان از روی این پروژه یک توزیع (Distribution) ایجاد و آن را با استفاده از ابزارهایی به مانند `Twine <https://twine.readthedocs.io/en/stable/>`_ یا `Poetry <https://python-poetry.org/>`_ بر روی PyPI منتشر ساخت. [برای کسب اطلاعات بیشتر میتوانید از `اسناد پایتون <https://packaging.python.org/en/latest/tutorials/packaging-projects/>`_ استفاده نمایید] |
119 | 102 |
|
120 | | -**docs**: در این دایرکتوری اسناد (راهنما، آموزش و...) پروژه قرار داده میشوند. ایجاد این اسناد توسط `Sphinx <http://sphinx-doc.org/>`_ در درسی جداگانه بررسی خواهد شد. |
| 103 | +در صورت علاقه میتوانید نگاهی نیز به پروژه `saeiddrv/PackagingPythonProjects <https://github.com/saeiddrv/PackagingPythonProjects>`_ بیاندازید که تمامی مراحل را به صورت کاربردی پیادهسازی کرده است. |
121 | 104 |
|
122 | | -**test**: این دایرکتوری محل نگهداری برنامه تست پروژه میباشد. ایجاد تست پروژه نیز در درسی جداگانه بررسی میگردد. این دایرکتوری میتواند هم در بالا ترین شاخه از پروژه و هم در داخل دایرکتوری سورس کد قرار داده شود. |
123 | 105 |
|
124 | | -با ایجاد یک توزیع (Distribution) از این ساختار و انتشار آن [که در آینده خواهید آموخت]، امکان نصب پروژه از طریق pip به وجود میآید. معمولا به جای واژه «توزیع» از واژه «بسته» (Package) استفاده میگردد؛ همانطور که pip نیز «سیستم مدیریت بسته پایتون» نامیده میشود و هیچگاه نباید آن را با مفهوم «بسته» که تا پیش از این مطرح شده است اشتباه گرفت. |
| 106 | +.. _source-code: |
125 | 107 |
|
126 | 108 | ایجاد سورس کد |
127 | 109 | --------------- |
|
0 commit comments