Ini adalah manual kecil / cerita tentang cara membuat paket pypi "sempurna" untuk python, yang dapat dipasang oleh siapa pun dengan perintah yang dihargai:
pip install my-perfect-package
Ini ditujukan untuk pemula, tetapi saya mendesak para profesional untuk mengekspresikan pendapat mereka tentang cara meningkatkan paket "sempurna". Karena itu, saya minta kucing.
Apa yang dimaksud dengan paket "ideal"?
Saya akan melanjutkan dari persyaratan berikut:
- Sumber terbuka di github;
Setiap orang harus dapat berkontribusi untuk pengembangan dan berterima kasih kepada penulis. - Dukungan untuk semua versi python saat ini / populer (2.7, 3.5, 3.6, 3.7, 3.8);
Ular berbeda, dan di suatu tempat masih aktif menulis di 2.7. - Cakupan 100% dengan unit test;
Tes unit meningkatkan arsitektur dan mengotomatiskan pemeriksaan regresi.
Lencana dengan nomor yang dihargai meningkatkan FAQ dan menetapkan bilah untuk orang lain . - Menggunakan CI:
Pemeriksaan otomatis sangat mudah! Dan banyak lencana keren
- Menjalankan tes unit pada semua platform dan pada semua versi python;
Jangan percaya mereka yang mengklaim bahwa python dan paket yang diinstal adalah cross-platform , karena Anda selalu dapat menemukan bug . - Pemeriksaan kode gaya;
Gaya seragam meningkatkan keterbacaan dan mengurangi jumlah diskusi kosong dalam ulasan. - Penganalisa kode statis;
Mencari bug dalam kode secara otomatis? Beri aku dua!
- Dokumentasi aktual;
Contoh bekerja dengan paket, deskripsi metode / kelas dan analisis kesalahan khas - pengalaman yang didokumentasikan akan mengurangi ambang entri untuk pemula. - Pengembangan lintas platform;
Sayangnya, sulit untuk memberikan kontribusi pribadi untuk proyek hanya karena pengembang mempertajam alat untuk Unix. Misalnya, saya menggunakan skrip bash untuk perakitan. - Paket ini berguna dan membuat dunia menjadi tempat yang lebih baik.
Suatu persyaratan yang sulit, karena dilihat dari jumlah paket dalam pypi (~ 210k), pengembang adalah altruis liar dan banyak yang telah ditulis.
Di mana untuk memulai?
Tidak ada ide bagus, jadi saya memilih topik yang usang dan sangat populer - bekerja dengan sistem angka. Versi pertama harus dapat menerjemahkan angka ke dalam bahasa Romawi dan sebaliknya. Untuk manual lebih rumit dan tidak perlu. Oh ya, yang terpenting adalah namanya: numsys - sebagai dekripsi sistem angka. numeral-system-py .
Bagaimana cara menguji?
Saya mengambil python3.7 dan pertama menulis tes dengan fungsi bertopik (kita semua TDD ) menggunakan modul unittests standar.
Saya membuat struktur proyek berikut:
src/ numeral-system/ __init__.py roman.py tests __init__.py test_roman.py
Saya tidak akan melakukan tes dalam paket, jadi saya pisahkan sekam . Awalnya, src/ tidak membuat folder src/ , tetapi pengembangan lebih lanjut menunjukkan bahwa lebih nyaman bagi saya untuk beroperasi. Ini tidak perlu, karena itu, sesuka hati.
Saya memutuskan untuk menggunakan pytest untuk diluncurkan - ia tahu cara bekerja dengan sempurna dengan tes dari modul standar. Mungkin terlihat sedikit tidak masuk akal, tetapi modul standar untuk tes kepada saya sepertinya tampak sedikit lebih nyaman. Sekarang saya akan merekomendasikan menggunakan gaya penulisan terbaik.
Tapi, mereka mengatakan bahwa menempatkan pytest (seperti dependensi lainnya) dalam sistem python bukanlah ide yang sangat cerdas ...
Bagaimana cara mengelola dependensi?
Hanya virtualenv dan requirements.txt dapat digunakan. Anda bisa menjadi progresif dan menggunakan puisi . Saya, mungkin, akan menggunakan racun - alat untuk menyederhanakan otomatisasi dan pengujian, yang juga akan memungkinkan saya untuk mengelola dependensi.
Saya membuat konfigurasi tox.ini sederhana dan menginstal pytest :
[tox] envlist = py37 ; , python3.7 [testenv] ; deps = `deps` , . -r requirements.txt ; -r requirements-test.txt ; commands = pytest ;
Awalnya, saya secara eksplisit menunjukkan dependensi, tetapi praktik integrasi dengan layanan pihak ketiga menunjukkan bahwa cara terbaik masih akan menyimpan dependensi dalam file requirements.txt .
Momen yang sangat halus muncul. Perbaiki versi saat ini pada saat pengembangan atau selalu menempatkan yang terbaru?
Jika Anda komit, maka selama instalasi mungkin ada konflik antara paket karena versi berbeda dari dependensi yang digunakan. Jika Anda tidak melakukan, maka paket tersebut mungkin tiba-tiba berhenti bekerja. Situasi yang terakhir ini sangat tidak menyenangkan untuk produk akhir, ketika semua bangunan dapat "berubah merah" dalam satu malam karena pembaruan kecil dari ketergantungan implisit. Dan menurut hukum Murphy, ini akan terjadi pada hari rilis.
Karena itu, saya mengembangkan aturan untuk diri saya sendiri:
- Selalu perbaiki versi untuk produk akhir, karena versi mana yang digunakan adalah tanggung jawab mereka.
- Jangan memperbaiki versi yang digunakan untuk paket yang diinstal. Atau batasi rentangnya jika fungsionalitas paket membutuhkannya.
Apa selanjutnya
Saya sedang menulis ujian!
Saya mengisi isi fungsinya, menambahkan komentar dan membuat tes berjalan dengan benar.
Pada titik ini, kebanyakan pengembang biasanya berhenti (saya masih percaya bahwa semua orang menulis tes =), menerbitkan paket dan meretas bug. Tapi saya pindah dan lompat ke lubang kelinci .
Bagaimana cara bekerja dengan berbagai versi python?
Dalam konfigurasi tox , tox menentukan peluncuran tes pada semua versi python yang menarik:
[tox] envlist = py{27,35,36,37,38}
Menggunakan pyenv, saya mengirimkan versi yang diperlukan untuk diri saya sendiri secara lokal sehingga tox dapat menemukannya dan membuat lingkungan pengujian.
Di mana 100% dihargai?
Saya akan menambahkan ukuran cakupan kode - untuk ini ada paket cakupan yang sangat baik dan integrasi yang sangat baik dengan pytest - pytest-cov .
requirements-test.txt sekarang terlihat seperti ini:
six=1.13.0 pytest=4.6.7 pytest-cov=2.8.1 parameterized=0.7.1
Menurut aturan di atas, saya memperbaiki versi paket yang digunakan untuk menjalankan tes.
Saya mengubah perintah uji coba:
deps = -r requirements.txt -r requirements-test.txt commands = pytest \ --cov=src/ \ --cov-config="{toxinidir}/tox.ini" \ --cov-append
Saya mengumpulkan statistik cakupan untuk semua kode dari src/ folder - paket itu sendiri ( numeral_system / ) dan diperlukan untuk kode uji ( tes / ) - Saya tidak ingin tes itu sendiri berisi bagian yang tidak dapat dieksekusi?
--cov-append perintah --cov-append semua statistik yang dikumpulkan untuk setiap panggilan di bawah versi python yang berbeda menjadi satu, karena cakupan untuk python kedua dan ketiga dapat berbeda (hi versi tergantung kode dan modul enam !), Tetapi totalnya memberikan 100 % Contoh sederhana:
if sys.version_info > (3, 0):
Tambahkan lingkungan baru untuk membuat laporan cakupan.
[testenv:coverage_report] deps = coverage commands = coverage html ; , coverage report --include="src/*" --fail-under=100 -m ; 100%
Dan saya menambahkan ke daftar lingkungan setelah menjalankan tes pada semua versi python.
[tox] envlist = py{27,35,36,37,38} coverage_report
Setelah menjalankan perintah tox , folder tox berisi file index.html dengan laporan yang indah akan muncul di root proyek.
Untuk lambang yang didambakan, saya mengintegrasikan 100% dengan layanan codecov , yang dengan sendirinya akan berintegrasi dengan github dan memungkinkan Anda untuk melihat riwayat perubahan cakupan kode. Untuk melakukan ini, tentu saja, Anda harus membuat akun di sana.
Lingkungan peluncuran terakhir adalah sebagai berikut:
[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,
Tetap sekarang hanya untuk menambahkan tautan ke lencana di 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
Banyak analis tidak ada, karena mereka, sebagian besar, saling melengkapi. Oleh karena itu, saya akan mengintegrasikan analisis statis populer yang akan memeriksa kepatuhan dengan PEP8 , menemukan masalah potensial dan perbaiki semua bug memformat kode secara seragam.
Anda harus segera mempertimbangkan di mana menentukan parameter untuk fine-tuning analisis. Untuk melakukan ini, Anda dapat menggunakan file setup.cfg , setup.cfg , satu file khusus, atau file tertentu untuk analisis. Saya memutuskan untuk menggunakan tox.ini secara langsung, karena Anda bisa menyalin tox.ini untuk proyek mendatang.
isort
isort adalah utilitas untuk memformat impor.
Saya membuat lingkungan berikut untuk menjalankan isort dalam mode format kode.
[testenv:isort] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort -y -sp={toxinidir}/tox.ini
Sayangnya, isort tidak dapat menentukan folder untuk pemformatan. Oleh karena itu, Anda harus mengubah direktori startup melalui changedir dan tentukan path ke file dengan pengaturan -sp={toxinidir}/tox.ini . Sakelar -y diperlukan untuk menonaktifkan mode interaktif.
Untuk menjalankan dalam pengujian, Anda memerlukan mode verifikasi - untuk ini ada tanda - --check-only :
[testenv:isort-check] changedir = {toxinidir}/src deps = isort==4.3.21 commands = isort --check-only -sp={toxinidir}/tox.ini
hitam
Selanjutnya, saya mengintegrasikan dengan formatter kode hitam . Saya melakukannya dengan analogi dengan isort :
[testenv:black] deps = black==19.10b0 commands = black src/ [testenv:black-check] deps = black==19.10b0 commands = black --check src/
Semuanya berfungsi dengan baik, tetapi ada konflik dengan isort - ada perbedaan dalam format impor .
Dalam salah satu komentar saya menemukan pengaturan isort kompatibel minimal, yang saya gunakan:
[isort] multi_line_output=3 include_trailing_comma=True force_grid_wrap=0 use_parentheses=True line_length=88
serpihan8
Selanjutnya, saya mengintegrasikan dengan analisis statis flake8 .
[testenv:flake8-check] deps = flake8==3.7.9 commands = flake8 --config=tox.ini src/
Ada masalah dengan integrasi dengan black lagi. Kita harus menambahkan penyetelan halus, yang sebenarnya direkomendasikan oleh black itu sendiri:
[flake8] max-line-length=88 ignore=E203
Sayangnya, pertama kali itu tidak berhasil. Jatuh dengan kesalahan E231 missing whitespace after ',' , saya harus menambahkan kesalahan ini untuk diabaikan:
[flake8] max-line-length=88 ignore=E203,E231
pylint
Integrasikan dengan penganalisis kode statis pylint
[testenv:pylint-check] deps = {[testenv]deps} # pylint , pylint==2.4.4 commands = pylint --rcfile=tox.ini src/
Saya segera menemukan batasan aneh - nama fungsi 30 karakter (ya, saya menulis nama metode pengujian yang sangat panjang) dan peringatan untuk keberadaan TODO dalam kode.
Saya harus menambahkan beberapa pengecualian:
[MESSAGES CONTROL] disable=fixme,invalid-name
Juga, saat yang tidak menyenangkan adalah bahwa pengembang pylint mengubur python2.7 dan tidak lagi mengembangkan paket untuk itu. Oleh karena itu, pemeriksaan harus dijalankan pada paket saat ini untuk python3.7 .
Tambahkan baris yang sesuai ke konfigurasi:
[tox] envlist = isort-check black-check flake8-check pylint-check py{27,35,36,37,38} coverage_report basepython = python3.7
Ini juga penting untuk menjalankan tes pada platform yang berbeda, karena versi standar python dalam sistem CI berbeda.
Ada apa dengan CI?
Pengantar
Integrasikan dengan appveyor - CI untuk windows. Pengaturan awal sederhana - semuanya bisa dilakukan di antarmuka, lalu unduh file yaml dan komit ke repositori.
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
Di sini saya secara eksplisit menentukan versi python3.7 , karena python2.7 akan digunakan secara default (dan tox juga akan menggunakan versi ini, walaupun saya secara eksplisit menentukan python3.7 ).
Tautan ke lencana, seperti biasa, ditambahkan ke 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
Setelah itu, saya mengintegrasikan dengan Travis CI - CI di Linux (dan di bawah MacOS dengan Windows, tetapi Python builds are not available on the macOS and Windows environments . Pengaturannya sedikit lebih rumit, karena file konfigurasi akan digunakan langsung dari repositori. Beberapa percobaan dan kesalahan iterasi - konfigurasi sudah siap, saya tekan satu commit yang indah dan permintaan penggabungan sudah siap.
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
( Pertanyaan retoris: Dan mengapa proyek CI sangat menyukai format yaml? )
Saya menunjukkan versi python3.8 , karena tidak berfungsi dengan benar melalui addon , dan Travis CI berhasil membuat virtualenv dari versi yang ditentukan.
Orang yang akrab dengan Travis CI mungkin bertanya, mengapa tidak secara eksplisit menentukan versi python dengan cara ini? Bagaimanapun, Travis CI secara otomatis membuat virtualenv dan menjalankan perintah yang diperlukan di dalamnya.
Alasannya adalah bahwa kita perlu mengumpulkan data cakupan kode dari semua versi. Tetapi tes akan dijalankan di pekerjaan yang berbeda secara paralel, itulah sebabnya mengapa tidak akan bekerja untuk mengumpulkan laporan cakupan umum.
Tentu saja, saya yakin sedikit lebih banyak pengertian dan ini bisa diperbaiki.
Secara tradisional, tautan ke lencana juga ditambahkan ke 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
Dokumentasi
Saya pikir setiap pengembang python telah menggunakan layanan setidaknya sekali - readthedocs.org . Menurut saya ini adalah layanan terbaik untuk hosting dokumentasinya.
Saya akan menggunakan alat standar untuk menghasilkan dokumentasi Sphinx . Saya mengikuti langkah-langkah dari manual awal dan mendapatkan struktur berikut:
src/ docs/ build/ # html source/ # _static/ # , , _templates/ # conf.py # index.rst # make.bat Makefile # make make
Selanjutnya, Anda perlu melakukan langkah-langkah minimum untuk mengonfigurasi:
github secara default menyarankan untuk membuat file README.md dalam format Markdown , ketika sphinx secara default disarankan menggunakan ReStructuredText .
Karena itu, saya harus menulis ulang dalam format .rst . Dan jika saya telah membaca manual mulai sampai akhir setidaknya sekali, saya menyadari bahwa sphinx dapat melakukannya di Markdown .
Saya README.rst file README.rst di index.rst
.. include:: ../../README.rst
- Untuk menghasilkan dokumentasi secara otomatis dari komentar di sumber, saya menambahkan ekstensi sphinx.ext.autodoc .
- Saya
conf.py folder paket ke conf.py Ini akan memungkinkan sphinx mengimpor kode kami untuk analisis.
import os import sys sys.path.insert(0, os.path.abspath('./../../src')) import numeral_system
- Saya menambahkan folder
docs/source/api-docs dan letakkan file deskripsi untuk setiap modul di sana. Dokumentasi harus dihasilkan secara otomatis dari komentar:
Roman numeral system ========================= .. automodule:: numeral_system.roman :members:
Setelah itu, proyek siap untuk mengungkapkan deskripsinya kepada dunia. Anda perlu membuat akun (lebih disukai melalui akun di github ) dan mengimpor proyek Anda, langkah-langkah rinci dijelaskan dalam instruksi .
Secara tradisi, saya menciptakan lingkungan yang tox :
[testenv:gen_docs] deps = -r docs/requirements.txt commands = sphinx-build -b html docs/source/ docs/build/
Saya menggunakan perintah sphinx-build secara eksplisit, bukan make , karena tidak ada di bawah Windows. Dan saya tidak ingin melanggar prinsip pengembangan lintas platform.
Segera setelah perubahan dibekukan, readthedocs.org akan secara otomatis mengumpulkan dokumentasi dan menerbitkannya.
Tapi ... Build failed . Saya tidak melakukan versi sphinx dan sphinx_rtd_theme , dan saya berharap readthedocs.org mengambil versi saat ini. Tapi ini tidak benar. Saya memperbaiki:
sphinx==2.3.1 sphinx_rtd_theme==0.4.3
Dan saya membuat file config khusus .readthedocs.yml untuk readthedocs.org , di mana saya menggambarkan lingkungan untuk meluncurkan build:
python: version: 3.7 install: - requirements: docs/requirements.txt - requirements: requirements.txt
Di sinilah fakta berguna bahwa dependensi berada dalam file requirements.txt . Saya menunggu bangunan dan dokumentasinya tersedia .
Tambahkan lencana lagi:
|Docs| .. |Docs| image:: https://readthedocs.org/projects/numeral-system-py/badge/?version=latest&style=flat :target: https://numeral-system-py.readthedocs.io/en/latest/
Perizinan
Perlu mempertimbangkan untuk memilih lisensi untuk paket tersebut.
Ini adalah topik yang sangat luas, jadi saya membaca artikel ini . Pada dasarnya, pilihannya adalah antara MIT dan Apache 2.0 . Saya menyukai frasa yang berhasil dikeluarkan dari konteks:
MIT
Saya setuju sepenuhnya, saya akan melakukannya. Jika rencananya berubah, Anda dapat dengan mudah mengubah lisensi (meskipun versi sebelumnya akan di bawah yang lama).
Sekali lagi, tambahkan lencana dewa lencana :
|License| .. |License| image:: https://img.shields.io/badge/License-MIT-yellow.svg :target: https://opensource.org/licenses/MIT
Di sini Anda dapat menemukan lencana untuk semua lisensi.
Bagaimana cara mengunggah ke pypi?
Pertama, Anda perlu membuat akun di pypi.org . Kemudian lanjutkan dengan persiapan paket.
Saya membuat setup.cfg
Penting untuk menggambarkan konfigurasi untuk menginstal / membangun paket dengan benar. Saya mengikuti instruksi . Dimungkinkan untuk mengatur data melalui setup.py , tetapi tidak ada opsi untuk mengatur beberapa parameter. Karena itu, gunakan file setup.cfg , di mana Anda dapat menentukan semua nuansa. Ditemukan templat kecil tentang cara mengisi file ini. Sebagai hasilnya, saya menggunakan keduanya dan file itu - lebih nyaman.
File ini juga dapat digunakan untuk mengkonfigurasi pylint , flake8 dan pengaturan lainnya, tetapi saya tidak melakukannya.
Bagaimana cara merakit paket?
Sekali lagi saya menulis sebuah lingkungan yang akan membantu saya menyusun paket yang diperlukan:
[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
Mengapa saya menghapus folder menggunakan python? Saya ingin mematuhi persyaratan untuk pengembangan lintas platform, tidak ada cara mudah untuk melakukan ini di Windows dan Unix.
Saya meluncurkan lingkungan pengujian:
tox -e build_wheel
Akibatnya, di folder dist saya dapatkan:
dist/ numeral-system_py-0.1.0.tar.gz numeral_system-py-0.1.0-py2.py3-none-any.whl
Saya isi!
Tidak juga.
Untuk memulainya, perlu memeriksa apakah paket itu bekerja dengan benar. Saya akan mengunggahnya ke repositori paket pengujian. Karena itu, Anda perlu membuat akun lain, tetapi sudah ada di test.pypi.org .
Saya menggunakan paket benang untuk ini - alat untuk mengisi artefak di PyPi.
[testenv:test_upload] skip_install = True deps = twine ; commands = python -m twine upload --repository-url https://test.pypi.org/legacy/ dist/*
Awalnya, proyek itu disebut numsys , tetapi ketika mencoba mengisinya, saya menemukan fakta bahwa sebuah paket dengan nama yang sama sudah ada! Dan apa yang paling menyebalkan - dia juga tahu cara mengonversi angka Romawi :) Dia tidak terlalu kesal dan berganti nama menjadi numeral-system-py .
Sekarang Anda perlu menginstal paket dari lingkungan pengujian. Validasi juga harus otomatis:
[testenv:test_venv] skip_install = True ; deps = ; commands = pip install -i https://test.pypi.org/simple/ numeral-system-py
Sekarang Anda hanya perlu menjalankan:
tox -e test_venv ... test_venv: commands_succeeded congratulations :)
Sepertinya berhasil :)
Sekarang pasti tuangkan!
Ya
Saya membuat lingkungan untuk mengunggah ke repositori produksi.
[testenv:pypi_upload] skip_install = True deps = twine commands = python -m twine upload dist/*
Dan lingkungan untuk verifikasi produksi.
[testenv:pypi_venv] skip_install = True deps = ; commands = pip install numeral-system-py
Apakah semuanya berfungsi?
Saya memeriksa dengan perintah sederhana:
> virtualenv venv > source venv/bin/activate (venv) > pip install numeral-system-py (venv) > python >>> import numeral_system >>> numeral_system.roman.encode(7) 'VII'
Semuanya hebat!
Saya memotong rilis di github , mengumpulkan paket dan mengisinya di propi pypi.
Komentar
Pembaruan Ketergantungan
Selama persiapan artikel ini, versi baru pytest dirilis, di mana, pada kenyataannya, dukungan untuk python 3.4 dijatuhkan ( sebenarnya dalam paket colorama ). Ada dua opsi:
- Versi colorama komit kompatibel dengan 3.4;
- Jatuhkan dukungan 3.4 :)
Dalam mendukung opsi kedua, argumen terakhir adalah bahwa pip menjatuhkan dukungan 3.4 di versi 19.1.
Ada juga dependensi tetap dalam bentuk penganalisa, pembuat format dan layanan lainnya. Ketergantungan ini dapat diperbarui secara bersamaan. Jika Anda beruntung, maka Anda hanya akan turun dengan versi upgrade, jika tidak, Anda harus memperbaiki kode atau bahkan menambahkan pengaturan.
TravisCI
Tidak mendukung python untuk MacOS dan Windows. Ada kesulitan dengan menjalankan tox untuk semua versi python dalam pekerjaan yang sama.
Versi paket
Perlu mematuhi versi semantik , yaitu format:
MAJOR.MINOR.PATCH
Versi paket dan beberapa parameter lain harus ditentukan untuk menginstal paket (dalam setup.cfg atau setup.py ) dan dalam dokumentasi. Untuk menghindari duplikasi, ia membuat indikasi hanya di paket numeral_system/__init__.py :
__version__ = '0.2.0'
Dan kemudian di setup.py secara eksplisit menggunakan variabel ini
setup(version=numeral_system.__version__)
Hal yang sama berlaku untuk di docs/source/conf.py
release = numeral_system.__version__
Hal di atas berlaku untuk setiap informasi meta - REAMDE.rst , deskripsi proyek, lisensi, nama penulis, dan banyak lagi.
Benar, ini mengarah pada fakta bahwa paket sedang diimpor pada saat perakitan, yang mungkin tidak diinginkan.
Duplikasi Ketergantungan
, 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 .
Lencana
— , , , . , .
coverage .
-
, , , . six , , type hint , asyncio — .
python2.7 , . , python3.5+, . , , CI . .
?
, :
Kesimpulan
open source , .
, python github , .
stackoverflow.com issues github .
. . ?..
, , .
, .
github .
Terima kasih