هذه كتيب / قصة صغيرة حول كيفية إنشاء حزمة pypi "مثالية" لـ python ، والتي يمكن لأي شخص تثبيتها باستخدام الأمر المحبب:
pip install my-perfect-package
إنه موجه للمبتدئين ، لكني أحث المحترفين على التعبير عن آرائهم حول كيفية تحسين الحزمة "المثالية". لذلك ، أطلب القط.
ماذا تعني الحزمة "المثالية"؟
سأنتقل من المتطلبات التالية:
- المصدر المفتوح على جيثب.
يجب أن يكون الجميع قادرين على المساهمة في تطوير وشكر المؤلف. - دعم لجميع الإصدارات الحالية / شعبية من الثعبان (2.7 ، 3.5 ، 3.6 ، 3.7 ، 3.8) ؛
تختلف الثعابين ، ولا تزال تكتب بنشاط في مكان ما على 2.7. - تغطية 100 ٪ مع اختبارات الوحدة ؛
تعمل اختبارات الوحدة على تحسين البنية وأتمتة اختبارات الانحدار.
ترفع الشارة التي تحمل رقمًا عزيزًا الأسئلة الشائعة وتعيين الشريط للآخرين . - باستخدام CI:
الشيكات التلقائية مريحة للغاية! وحفنة من شارات باردة
- تشغيل اختبارات الوحدة على جميع المنصات وعلى جميع إصدارات بيثون ؛
لا تصدق أولئك الذين يزعمون أن بيثون والحزم المثبتة هي منصات مشتركة ، لأنه يمكنك دائمًا العثور على خطأ . - التحقق من رمز النمط ؛
يعمل النمط الموحد على تحسين قابلية القراءة ويقلل من عدد المناقشات الفارغة في المراجعة. - محلل الكود الثابت
البحث التلقائي عن الأخطاء في الكود؟ أعطني اثنين!
- الوثائق الفعلية
أمثلة على العمل مع الحزمة ، ووصف الأساليب / الطبقات وتحليل الأخطاء النموذجية - تجربة موثقة سوف تقلل من عتبة الدخول للمبتدئين. - التنمية عبر منصة.
لسوء الحظ ، من الصعب تقديم مساهمة شخصية للمشاريع لمجرد أن المطور شحذ أدوات يونكس. على سبيل المثال ، استخدمت نصوص bash للتجميع. - الحزمة مفيدة وتجعل العالم مكانًا أفضل.
يعد هذا مطلبًا صعبًا ، نظرًا للحكم على عدد الحزم في pypi (~ 210k) ، فإن المطورين هم من علماء الإيثار المتوحشون وقد تمت كتابة الكثير بالفعل.
من أين تبدأ؟
لم تكن هناك أفكار جيدة ، لذلك اخترت موضوعًا مشهورًا وشائعًا للغاية - العمل مع أنظمة الأرقام. يجب أن تكون النسخة الأولى قادرة على ترجمة الأرقام إلى اللغة الرومانية والعكس صحيح. للدليل هو أكثر تعقيدا وليس ضروريا. نعم ، الأهم هو الاسم: numsys - باعتباره فك تشفير أنظمة الأرقام. نظام الأرقام الحمر .
كيف تختبر؟
أخذت python3.7 وكتبت الاختبارات الأولى مع كعب الروتين وظيفة (نحن جميعا TDDs ) باستخدام وحدة unittests القياسية.
أقوم بعمل هيكل المشروع التالي:
src/ numeral-system/ __init__.py roman.py tests __init__.py test_roman.py
لن أضع اختبارات في العبوة ، لذلك أنا منفصل الغث والسمين . في البداية ، لم src/ بإنشاء src/ folder ، لكن التطوير الإضافي أظهر أنه أكثر ملاءمة لي للعمل. هذا ليس ضروريا ، لذلك ، في الإرادة.
قررت استخدام pytest للإطلاق - فهو يعرف كيفية العمل بشكل مثالي مع اختبارات الوحدة النمطية القياسية. قد يبدو غير منطقي بعض الشيء ، ولكن الوحدة النمطية للاختبارات بالنسبة لي يبدو بدا أكثر راحة قليلا. الآن أوصي باستخدام أسلوب pytest للكتابة.
ولكن ، يقولون أن وضع pytest (مثل أي تبعيات أخرى) في بيثون النظام ليست فكرة ذكية للغاية ...
كيفية إدارة التبعيات؟
يمكن استخدام virtualenv و requirements.txt فقط. يمكنك أن تكون التقدمية واستخدام الشعر . ربما ، سوف أستخدم توكس - أداة لتبسيط الأتمتة والاختبار ، مما سيسمح لي أيضًا بإدارة التبعيات.
يمكنني إنشاء تهيئة tox.ini بسيطة وتثبيت pytest :
[tox] envlist = py37 ; , python3.7 [testenv] ; deps = `deps` , . -r requirements.txt ; -r requirements-test.txt ; commands = pytest ;
في البداية ، أشرت صراحة إلى التبعيات ، لكن ممارسة التكامل مع خدمات الجهات الخارجية أظهرت أن أفضل طريقة لتخزين التبعيات في ملف requirements.txt .
لحظة خفية جدا تنشأ. إصلاح الإصدار الحالي في وقت التطوير أو دائما وضع آخر؟
إذا كنت تلتزم ، فقد يكون هناك تعارض بين الحزم أثناء التثبيت بسبب وجود إصدارات مختلفة من التبعيات المستخدمة. إذا لم تلتزم ، فقد تتوقف الحزمة فجأة عن العمل. الموقف الأخير غير سارة للغاية بالنسبة للمنتجات النهائية ، حيث قد تتحول جميع البنيات إلى اللون الأحمر في ليلة واحدة بسبب تحديث بسيط للاعتماد الضمني. وفقًا لقانون مورفي ، سيحدث هذا في يوم الإفراج.
لذلك ، وضعت قاعدة لنفسي:
- قم دائمًا بإصلاح إصدار المنتجات النهائية ، نظرًا لأن الإصدارات المراد استخدامها هي مسؤوليتها.
- لا تقم بإصلاح الإصدار المستخدم للحزم المثبتة. أو حدده بنطاق إذا كانت وظيفة الحزمة تتطلب ذلك.
ما التالي؟
أنا أكتب اختبارات!
أملأ مجموعة الوظائف ، وأضيف تعليقات وأجري الاختبارات بشكل صحيح.
في هذه المرحلة ، عادةً ما يتوقف معظم المطورين (ما زلت أعتقد أن كل شخص يكتب اختبارات =) ، ثم نشر الحزمة واختراق الأخطاء. لكنني أتقدم والقفز في حفرة الأرنب .
كيفية العمل مع إصدارات مختلفة من الثعبان؟
في تكوين tox ، حدد إطلاق الاختبارات على جميع إصدارات python المثيرة للاهتمام:
[tox] envlist = py{27,35,36,37,38}
باستخدام pyenv ، أقوم بتسليم الإصدارات اللازمة لنفسي محليًا حتى يتمكن tox العثور عليها وإنشاء بيئات اختبار.
أين هي العزيزة 100 ٪؟
سأضيف مقياسًا لتغطية الكود - لذلك هناك حزمة تغطية ممتازة ولا تقل تكاملاً ممتازًا مع pytest - pytest-cov .
requirements-test.txt يبدو الآن مثل هذا:
six=1.13.0 pytest=4.6.7 pytest-cov=2.8.1 parameterized=0.7.1
وفقًا للقاعدة أعلاه ، أقوم بإصلاح إصدارات الحزم التي يتم استخدامها لإجراء الاختبارات.
أقوم بتغيير أمر تشغيل الاختبار:
deps = -r requirements.txt -r requirements-test.txt commands = pytest \ --cov=src/ \ --cov-config="{toxinidir}/tox.ini" \ --cov-append
أقوم بتجميع إحصاءات التغطية لكل الشفرة من src/ folder - الحزمة نفسها ( numeral_system / ) والمطلوبة لرمز الاختبار ( الاختبارات / ) - لا أريد أن تحتوي الاختبارات نفسها على أجزاء غير قابلة للتنفيذ؟
--cov-append command --cov-append كل الإحصائيات التي تم جمعها لكل مكالمة بموجب إصدار مختلف من python في واحد ، لأن تغطية الثعبان الثاني والثالث يمكن أن تكون مختلفة (الرمز المعتمد على الإصدار والوحدة السادسة !) ، ولكن في المجموع ، أعطي 100 ٪. مثال بسيط:
if sys.version_info > (3, 0):
أضف بيئة جديدة لإنشاء تقرير تغطية.
[testenv:coverage_report] deps = coverage commands = coverage html ; , coverage report --include="src/*" --fail-under=100 -m ; 100%
وأضيف إلى قائمة البيئات بعد إجراء الاختبارات على جميع إصدارات بيثون.
[tox] envlist = py{27,35,36,37,38} coverage_report
بعد تشغيل الأمر tox ، يجب أن tox مجلد tox يحتوي على ملف index.html مع تقرير جميل في جذر المشروع.
بالنسبة للشارة المرغوبة ، أدمج 100٪ مع خدمة codecov ، التي ستندمج بالفعل مع github وتتيح لك عرض تاريخ تغييرات تغطية الشفرة. للقيام بذلك ، بالطبع ، سيكون عليك إنشاء حساب هناك.
بيئة الإطلاق النهائية هي كما يلي:
[testenv:coverage_report] deps = coverage==5.0.2 codecov==2.0.15 commands = coverage html coverage report --include="src/*" --fail-under=100 -m coverage xml codecov -f coverage.xml --token=2455dcfa-f9fc-4b3a-b94d-9765afe87f0f ; codecov,
يبقى الآن فقط لإضافة رابط إلى الشارة في README.rst :
|Code Coverage| .. |Code Coverage| image:: https://codecov.io/gh/zifter/numeral-system-py/branch/master/graph/badge.svg :target: https://codecov.io/gh/zifter/numeral-system-py
لا يوجد الكثير من المحللين لأنهم ، في معظمهم ، يكملون بعضهم البعض. لذلك ، سأقوم بدمج أجهزة التحليل الثابتة الشهيرة التي ستتحقق من الالتزام بـ PEP8 ، وأجد المشاكل المحتملة و إصلاح جميع الأخطاء تنسيق موحد الرمز.
يجب عليك أن تأخذ بعين الاعتبار على الفور مكان تحديد المعلمات لضبط المحللين. للقيام بذلك ، يمكنك استخدام ملف setup.cfg أو setup.cfg أو ملف مخصص واحد أو ملفات محددة setup.cfg . قررت استخدام tox.ini مباشرة ، حيث يمكنك فقط نسخ tox.ini للمشاريع المستقبلية.
isort
isort هي أداة مساعدة لتنسيق الواردات.
يمكنني إنشاء البيئة التالية لتشغيل isort في وضع تنسيق التعليمات البرمجية.
[testenv:isort] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort -y -sp={toxinidir}/tox.ini
لسوء الحظ ، لا يمكن لـ isort تحديد مجلد للتنسيق. لذلك ، يجب عليك تغيير دليل بدء التشغيل عبر changedir وتحديد المسار إلى الملف باستخدام الإعدادات -sp={toxinidir}/tox.ini . يلزم التبديل -y لتعطيل الوضع التفاعلي.
للتشغيل في الاختبارات ، تحتاج إلى وضع تحقق - ولهذا ، توجد علامة تحقق --check-only :
[testenv:isort-check] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort --check-only -sp={toxinidir}/tox.ini
أسود
بعد ذلك ، أدمج مع منسق الكود الأسود . أفعل ذلك عن طريق القياس مع isort :
[testenv:black] deps = black==19.10b0 commands = black src/ [testenv:black-check] deps = black==19.10b0 commands = black --check src/
كل شيء يعمل بشكل جيد ، ولكن هناك تعارض مع isort - هناك فرق في تنسيق الواردات .
في أحد التعليقات ، وجدت إعداد isort متوافق الحد الأدنى ، والذي استخدمته:
[isort] multi_line_output=3 include_trailing_comma=True force_grid_wrap=0 use_parentheses=True line_length=88
flake8
بعد ذلك ، أدمج مع محلل ثابت flake8 .
[testenv:flake8-check] deps = flake8==3.7.9 commands = flake8 --config=tox.ini src/
هناك مشاكل مع التكامل مع black مرة أخرى. علينا أن نضيف ضبطًا دقيقًا ، والذي في الحقيقة ، يوصى به black نفسه:
[flake8] max-line-length=88 ignore=E203
لسوء الحظ ، في المرة الأولى لم تنجح. سقط مع الخطأ E231 missing whitespace after ',' ، اضطررت إلى إضافة هذا الخطأ لتجاهل:
[flake8] max-line-length=88 ignore=E203,E231
pylint
دمج مع محلل كود ثابت pylint
[testenv:pylint-check] deps = {[testenv]deps} # pylint , pylint==2.4.4 commands = pylint --rcfile=tox.ini src/
واجهت على الفور قيودًا غريبة - أسماء الوظائف المكونة من 30 حرفًا (نعم ، أكتب أسماء طويلة جدًا من طرق الاختبار) وتحذيرات لوجود TODO في الكود.
يجب أن أضيف بعض الاستثناءات:
[MESSAGES CONTROL] disable=fixme,invalid-name
كذلك ، فإن اللحظة غير السارة هي أن مطوري pylint دفنوا بالفعل python2.7 ولم يعدوا يطورون حزمة لذلك. لذلك ، يجب تشغيل الشيكات على الحزمة الحالية لـ python3.7 .
أضف السطر المناسب إلى التكوين:
[tox] envlist = isort-check black-check flake8-check pylint-check py{27,35,36,37,38} coverage_report basepython = python3.7
من المهم أيضًا إجراء الاختبارات على منصات مختلفة ، نظرًا لأن الإصدار الافتراضي من python في أنظمة CI مختلف.
ما الأمر مع CI؟
Appveyor
دمج مع appveyor - CI للنوافذ. الإعداد الأولي بسيط - كل شيء يمكن القيام به في الواجهة ، ثم قم بتنزيل ملف yaml وإلزامه بالمستودع.
version: 0.0.{build} install: - cmd: >- C:\\Python37\\python -m pip install --upgrade pip C:\\Python37\\pip install tox build: off test_script: - cmd: C:\\Python37\\tox
هنا أقوم بتحديد إصدار python3.7 بشكل صريح ، حيث سيتم استخدام python2.7 افتراضيًا (وسيستخدم tox أيضًا هذا الإصدار ، على الرغم من أنني حددت python3.7 بشكل صريح).
يضاف رابط الشارة ، كالعادة ، إلى README.rst
|Build status Appveyor| .. |Build status Appveyor| image:: https://ci.appveyor.com/api/projects/status/github/zifter/numeral-system-py?branch=master&svg=true :target: https://ci.appveyor.com/project/zifter/numeral-system-py
ترافيس سي
بعد ذلك ، أدمج مع Travis CI - CI ضمن Linux (وتحت MacOS مع Windows ، ولكن Python builds are not available on the macOS and Windows environments . الإعداد أكثر تعقيدًا قليلاً ، حيث سيتم استخدام ملف التكوين مباشرة من المستودع. التكوين جاهز ، اسكواش في التزام جميل واحد وطلب الدمج جاهز.
language: python python: 3.8 # dist: xenial # required for Python 3.7 (travis-ci/travis-ci#9069) sudo: required # required for Python 3.7 (travis-ci/travis-ci#9069) addons: apt: sources: - deadsnakes packages: - python3.5 - python3.6 - python3.7 - pypy install: - pip install tox script: - tox
( سؤال بلاغي: ولماذا مشاريع CI مثل تنسيق yaml كثيرا؟ )
أشير إلى إصدار python3.8 ، لأنه لم يعمل بشكل صحيح من خلال addon ، ويقوم Travis CI بإنشاء virtualenv بنجاح من الإصدار المحدد.
قد يسأل الأشخاص المطلعون على Travis CI ، لماذا لا تحدد إصدارات بيثون صراحة بهذه الطريقة؟ بعد كل شيء ، يقوم Travis CI تلقائيًا بإنشاء virtualenv وتنفيذ الأوامر اللازمة فيه.
السبب هو أننا نحتاج إلى جمع بيانات تغطية الكود من جميع الإصدارات. ولكن سيتم تشغيل الاختبارات في وظائف مختلفة بشكل متوازٍ ، ولهذا السبب لن تعمل على جمع تقرير تغطية عام.
بالطبع ، أنا متأكد من أنه أكثر قليلاً فهم ويمكن إصلاح هذا.
حسب التقاليد ، يتم أيضًا إضافة رابط إلى شارة إلى README.rst
|Build Status Travis CI| .. |Build Status Travis CI| image:: https://travis-ci.org/zifter/numeral-system-py.svg?branch=master :target: https://travis-ci.org/zifter/numeral-system-py
الوثائق
أعتقد أن كل مطور بيثون قد استخدم الخدمة مرة واحدة على الأقل - readthedocs.org . يبدو لي أن هذه هي أفضل خدمة لاستضافة وثائقها.
سأستخدم الأداة القياسية لإنشاء وثائق Sphinx . أتبع الخطوات من دليل البدء وأحصل على الهيكل التالي:
src/ docs/ build/ # html source/ # _static/ # , , _templates/ # conf.py # index.rst # make.bat Makefile # make make
بعد ذلك ، يجب عليك القيام بالخطوات الدنيا للتكوين:
github بشكل افتراضي يقترح إنشاء ملف README.md بتنسيق README.md ، عندما يقترح sphinx افتراضيًا استخدام ReStructuredText .
لذلك ، اضطررت إلى إعادة .rst بتنسيق .rst . وإذا كنت قد قرأت دليل البدء حتى النهاية مرة واحدة على الأقل ، أدركت أن sphinx يمكنه فعل ذلك في تخفيض السعر .
أقوم README.rst ملف index.rst في index.rst
.. include:: ../../README.rst
- لإنشاء الوثائق تلقائيًا من التعليقات في المصدر ، أضف الامتداد sphinx.ext.autodoc .
- أقوم
conf.py مجلد الحزمة إلى conf.py هذا سيسمح sphinx باستيراد الكود الخاص بنا للتحليل.
import os import sys sys.path.insert(0, os.path.abspath('./../../src')) import numeral_system
- أقوم بإضافة مجلد
docs/source/api-docs وإسقاط ملف الوصف لكل وحدة نمطية هناك. يجب أن يتم إنشاء الوثائق تلقائيًا من التعليقات:
Roman numeral system ========================= .. automodule:: numeral_system.roman :members:
بعد ذلك ، فإن المشروع جاهز للكشف عن وصفه للعالم. تحتاج إلى إنشاء حساب (يفضل أن يكون ذلك من خلال حساب على github ) واستيراد مشروعك ، والخطوات التفصيلية الموضحة في التعليمات .
حسب التقاليد ، أقوم بتهيئة بيئة tox :
[testenv:gen_docs] deps = -r docs/requirements.txt commands = sphinx-build -b html docs/source/ docs/build/
يمكنني استخدام الأمر sphinx-build بشكل صريح ، بدلاً من make ، لأنه غير موجود تحت Windows. وأنا لا أريد أن تنتهك مبدأ التنمية عبر منصة.
بمجرد تجميد التغييرات ، ستقوم readthedocs.org بجمع الوثائق تلقائيًا ونشرها.
لكن ... Build failed . لم ألتزم sphinx_rtd_theme sphinx و sphinx_rtd_theme ، وكنت أتوقع readthedocs.org تأخذ readthedocs.org الإصدارات الحالية. لكن هذا ليس كذلك. أنا إصلاح:
sphinx==2.3.1 sphinx_rtd_theme==0.4.3
وأقوم بإنشاء ملف تهيئة خاص .readthedocs.yml لـ readthedocs.org ، حيث أصف البيئة اللازمة لبدء readthedocs.org :
python: version: 3.7 install: - requirements: docs/requirements.txt - requirements: requirements.txt
هذا هو المكان الذي أصبحت فيه الحقيقة مفيدة في أن التبعيات موجودة في ملفات requirements.txt . أنا في انتظار الإنشاء وتصبح الوثائق متاحة .
أضف الشارة مرة أخرى:
|Docs| .. |Docs| image:: https://readthedocs.org/projects/numeral-system-py/badge/?version=latest&style=flat :target: https://numeral-system-py.readthedocs.io/en/latest/
الترخيص
يجدر النظر في اختيار ترخيص للحزمة.
هذا موضوع واسع للغاية ، لذلك قرأت هذا المقال . في الأساس ، يكون الاختيار بين MIT و Apache 2.0 . أعجبتني العبارة التي أخرجت بنجاح من السياق:
MIT
أوافق تمامًا ، سأفعل ذلك ، فإذا تغيرت الخطط ، يمكنك بسهولة تغيير الترخيص (على الرغم من أن الإصدارات السابقة ستكون تحت الإصدار القديم).
مرة أخرى ، أضف شارة شارة الله :
|License| .. |License| image:: https://img.shields.io/badge/License-MIT-yellow.svg :target: https://opensource.org/licenses/MIT
هنا يمكنك العثور على شارات لجميع التراخيص.
كيفية التحميل إلى pypi؟
تحتاج أولاً إلى إنشاء حساب على pypi.org . ثم المضي قدما في إعداد الحزمة.
أنا أصنع setup.cfg
من الضروري أن تصف بشكل صحيح التكوين لتثبيت / بناء الحزمة. لقد اتبعت التعليمات . من الممكن ضبط البيانات عبر setup.py ، لكن لا توجد خيارات لضبط بعض المعلمات. لذلك ، استخدم ملف setup.cfg ، حيث يمكنك تحديد جميع الفروق الدقيقة. العثور على قالب صغير حول كيفية ملء هذا الملف. نتيجةً لذلك ، استخدم كل من هذا الملف وهذا الملف - إنه أكثر ملاءمة.
يمكن أيضًا استخدام هذا الملف لتكوين pylint و flake8 والإعدادات الأخرى ، لكنني لم pylint flake8 .
كيفية تجميع حزمة؟
مرة أخرى ، أكتب بيئة ستساعدني في إعداد الحزمة الضرورية:
[testenv:build_wheel] skip_install = True deps = ; wheel docutils pygments commands = python -c 'import shutil; (shutil.rmtree(p, ignore_errors=True) for p in ["build", "dist"]);' python setup.py sdist bdist_wheel
لماذا أحذف المجلدات باستخدام بيثون؟ أريد الالتزام بمتطلبات التطوير عبر الأنظمة الأساسية ، لا توجد طريقة ملائمة للقيام بذلك ضمن Windows و Unix.
أطلق بيئة الاختبار:
tox -e build_wheel
نتيجة لذلك ، في مجلد dist أحصل على:
dist/ numeral-system_py-0.1.0.tar.gz numeral_system-py-0.1.0-py2.py3-none-any.whl
أنا في ملء!
ليس حقا
بادئ ذي بدء ، يجدر التحقق من أن الحزمة تعمل بشكل صحيح. سنقوم بتحميله إلى مستودع حزمة الاختبار. لذلك ، تحتاج إلى إنشاء حساب آخر ، ولكن بالفعل على test.pypi.org .
أنا استخدم حزمة خيوط لهذا - أداة لملء القطع الأثرية في PyPi.
[testenv:test_upload] skip_install = True deps = twine ; commands = python -m twine upload --repository-url https://test.pypi.org/legacy/ dist/*
في البداية ، كان يُطلق على المشروع اسم numsys ، ولكن عندما حاولت numsys ، numsys وجود حزمة بنفس الاسم بالفعل! والأكثر إزعاجًا - إنه يعرف أيضًا كيف يتحول إلى أرقام رومانية :) لم يكن منزعجًا جدًا وتمت إعادة تسميته ليصبح numeral-system-py .
تحتاج الآن إلى تثبيت الحزمة من بيئة الاختبار. يجب أن يكون التحقق من الصحة تلقائيًا أيضًا:
[testenv:test_venv] skip_install = True ; deps = ; commands = pip install -i https://test.pypi.org/simple/ numeral-system-py
الآن تحتاج فقط إلى تشغيل:
tox -e test_venv ... test_venv: commands_succeeded congratulations :)
يبدو أن العمل :)
الآن بالتأكيد صب!
نعم.
أقوم بإنشاء بيئة للتحميل إلى مستودع الإنتاج.
[testenv:pypi_upload] skip_install = True deps = twine commands = python -m twine upload dist/*
والبيئة للتحقق الإنتاج.
[testenv:pypi_venv] skip_install = True deps = ; commands = pip install numeral-system-py
هل كل شيء يعمل؟
أتحقق من الأوامر البسيطة:
> virtualenv venv > source venv/bin/activate (venv) > pip install numeral-system-py (venv) > python >>> import numeral_system >>> numeral_system.roman.encode(7) 'VII'
كل شيء رائع!
قمت بقطع الإصدار على جيثب ، وجمع العبوة واملأها بـ propi pypi.
تصريحات
تحديثات التبعية
أثناء إعداد هذه المقالة ، تم إصدار نسخة جديدة من pytest ، وفي الواقع ، تم إسقاط دعم python 3.4 ( فعليًا في حزمة colorama ). كان هناك خياران:
- ارتكاب نسخة colorama متوافقة مع 3.4 ؛
- انخفاض الدعم 3.4 :)
لصالح الخيار الثاني ، كانت الحجة الأخيرة هي أن pip انخفضت الدعم 3.4 في الإصدار 19.1.
هناك أيضًا تبعيات ثابتة في شكل أجهزة تحليل وتنسيقات وخدمات أخرى. يمكن تحديث هذه التبعيات في نفس الوقت. إذا كنت محظوظًا ، فلن تحصل إلا على إصدار الترقية ؛ وإذا لم يكن الأمر كذلك ، فسيتعين عليك تصحيح التعليمات البرمجية أو حتى إضافة الإعدادات.
TravisCI
لا يدعم بيثون لنظام التشغيل MacOS و Windows. هناك صعوبات في تشغيل tox لجميع إصدارات بيثون داخل نفس الوظيفة.
حزمة الإصدار
من الضروري الالتزام بالإصدار الدلالي ، أي التنسيق:
MAJOR.MINOR.PATCH
يجب تحديد إصدار الحزمة وبعض المعلمات الأخرى لتثبيت الحزمة (في setup.cfg أو setup.cfg ) وفي الوثائق. لتجنب الازدواجية ، قدم إشارة فقط في الحزمة numeral_system/__init__.py :
__version__ = '0.2.0'
ثم في setup.py أستخدم هذا المتغير بشكل صريح
setup(version=numeral_system.__version__)
وينطبق الشيء نفسه في docs/source/conf.py
release = numeral_system.__version__
ما سبق ينطبق على أي معلومات تعريف - REAMDE.rst ، ووصف المشروع ، والتراخيص ، وأسماء المؤلفين ، وأكثر من ذلك.
صحيح ، هذا يؤدي إلى حقيقة أن الحزمة يتم استيرادها في وقت التجميع ، وهو ما قد يكون غير مرغوب فيه.
التبعية الازدواجية
في البداية ، كنت مرتبكًا من حقيقة أنني كنت بحاجة لتحديد التبعيات الخاصة بالحزمة في requirements.txt و setup.cfg .
, — setup.cfg .
. , requirements-dev.txt .
, src/ . :
:
— .
, :
Add badge with supported version Support for py38
:
Try fix py38 env creating Try fix py38 env creating Try fix py38 env creating Fix check
, 3 ! Travis CI.
, . — , .
, . CHANGELOG .
الوثائق
, Markdown . , rst .
شارات
— , , , . , .
coverage .
-
, , , . six , , type hint , asyncio — .
python2.7 , . , python3.5+, . , , CI . .
?
, :
استنتاج
open source , .
, python github , .
stackoverflow.com issues github .
. . ?..
, , .
, .
github .
شكرا لك