Shulou(Shulou.com)06/03 Report--

In this issue, the editor will bring you about the correct posture of releasing the Python package in 2021. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

If you're like me, you occasionally write a useful python utility Mini Program that you'd like to share with your colleagues. The best way to do this is to make a Python package: it's easy to install and avoids copying.

You may think that creating a software package is troublesome. Actually, that's not going to happen anymore. I will explain it through this step-by-step guide. You only need to perform three main steps (and a series of optional steps), supplemented by a few GitHub links.

1. Initialization

We will create podsearch, a utility to search for podcasts in iTunes. Let's create a directory and a virtual environment:

$mkdir podsearch $cd podsearch $python3-m venv env $. Env/bin/activate

Define a minimum package structure:

. ├── .gitignore └── podsearch └── _ _ init__.py "" Let's find some podcasts! "_ version__ =" 0.1.0 "def search (name, count=5):" Search podcast by name. "" Raise NotImplementedError () 2. Test package

Creating a package with Python used to be a cumbersome task. Fortunately, there is a great flit (https://flit.readthedocs.io/en/latest/) Mini Program) that simplifies everything. Let's install it:

Pip install flit

And create a package description:

Flit init Module name [podsearch]: Author [Anton Zhiyanov]: Author email [m@antonz.org]: Home page [https://github.com/nalgeon/podsearch-py]: Choose a license (see http://choosealicense.com/ for more info) 1. MIT-simple and permissive 2. Apache-explicitly grants patent rights 3. GPL-ensures that code based on this is shared with the same terms 4. Skip-choose a license later Enter 1-4 [1]: 1 Written pyproject.toml; edit that file to add optional extra info.

Pyproject.toml

Flit has created a pyproject.toml-project metadata file. It already has everything you need to publish the package to the common repository, PyPI.

Register TestPyPi (test repository) and PyPI (primary repository). They are completely independent, so you will need two accounts.

Set access to the repository in ~ / .pypirc:

[distutils] index-servers = pypi pypitest [pypi] username: nalgeon # replace with your PyPI username [pypitest] repository: https://test.pypi.org/legacy/ username: nalgeon # replace with your TestPyPI username

And publish the package to the test repository:

$flit publish-repository pypitest Found 4 files tracked in git... Package is at https://test.pypi.org/project/podsearch/

Over! The package is available on TestPyPi.

3. Open software package

Let's improve the code so that it can actually search for podcasts:

#... SEARCH_URL = "https://itunes.apple.com/search" @ dataclass class Podcast:" Podcast metadata. "" Id: str name: str author: str url: str feed: Optional [str] = None category: Optional [str] = None image: Optional [str] = None def search (name: str, limit: int = 5)-> List [Podcast]: "" Search podcast by name. "" Params= {"term": name, "limit": limit, "media": "podcast"} response = _ get (url=SEARCH_URL, params=params) return _ parse (response)

And publish to the main repository-PyPI. Perform this step only if your package contains useful code. Do not publish invalid packages and stubs.

Flit publish

Release complete! It's time to share it with your colleagues. To make the package easy to use, I recommend that you perform the following steps.

a. README file Readme and change log changelog

No one likes to write documents. However, without documentation, people are less likely to want to install your package, so we need to add README.md and CHANGELOG.md.

README.md

CHANGELOG.md

Add README to pyproject.toml so that PyPI displays it on the package page:

Description-file = "README.md"

Also specify the minimum supported Python version:

Requires-python = "> = 3.7"

Update the version in _ _ init__.py and release the package through flit publish:

B.Linters and tests

Consider formatting (black), test coverage (coverage), code quality (flake8,pylint,mccabe), and static analysis (mypy). We will handle everything through tox.

$pip install black coverage flake8 mccabe mypy pylint pytest tox

Create a tox configuration in tox.ini:

[tox] isolated_build = True envlist = py37,py38,py39 [testenv] deps = black coverage flake8 mccabe mypy pylint pytest commands = black podsearch flake8 podsearch pylint podsearch mypy podsearch coverage erase coverage run-- include=podsearch/*-m pytest-ra coverage report-m

Tox.ini

And run all checks:

$tox-e py39... Py39 run-test: commands [0] | black podsearch All done!. Py39 run-test: commands [2] | pylint podsearch Your code has been rated at 10.00 pylint podsearch Your code has been rated at 10 (previous run: 10.00 Universe 10, + 0.00). Py39 run-test: commands [6] | coverage report-m TOTAL 100%. Py39: commands succeeded congratulations:)

The linters test passed, and the test passed, with a coverage rate of 100%.

c. Cloud building

Every reliable open source project will be cloud tested after each submission, so we will do the same. A good additional effect is that there are beautiful badges in the README file.

Let's build the project using GitHub Actions, check test coverage using Codecov, and check code quality using Code Climate.

You will have to register Codecov and Code Climate (both support GitHub login) and enable the package repository in the settings.

After that, add the GitHub Actions build configuration to .GitHub / workflows / build.yml:

#... Jobs: build: runs-on: ubuntu-latest strategy: matrix: python-version: [3.7, 3.8 Env: USING_COVERAGE: "3.9" steps:-name: Checkout sources uses: actions/checkout@v2-name: Set up Python uses: actions/setup-python@v2 with: python-version: $- Name: Install dependencies run: | python-m pip install-- upgrade pip python-m pip install black coverage flake8 flit mccabe mypy pylint pytest tox tox-gh-actions-name: Run tox run: | python-m tox- name: Upload coverage to Codecov uses: codecov/ Codecov-action@v1 if: contains (env.USING_COVERAGE Matrix.python-version) with: fail_ci_if_error: true

Build.yml

As we did before, GitHub is tested through tox. The tox-gh-actions package and USING_COVERAGE settings ensure that tox uses the same version of Python as the GitHub Actions required by strategy.matrix.

The final step sends the test coverage to Codecov. Code Climate does not require a separate step-it automatically discovers repository changes.

Now, submit, push and enjoy the results in a minute. And make everyone like to add badges to README.md:

[! [PyPI Version] [pypi-image]] [pypi-url] [! [Build Status] [build-image]] [build-url] [! [Code Coverage] [coverage-image]] [coverage-url] [! [Code Quality] [quality-image]] [quality-url]... [pypi-image]: https://img.shields.io/pypi/v/podsearch [pypi-url]: https://pypi.org/project/podsearch/ [build-image]: https://github.com/nalgeon/podsearch-py/actions/workflows/build.yml/badge.svg [build-url]: https://github.com/nalgeon/podsearch-py/actions/workflows/build.yml [coverage-image]: https://codecov.io/gh/nalgeon/podsearch-py/ Branch/main/graph/badge.svg [coverage-url]: https://codecov.io/gh/nalgeon/podsearch-py [quality-image]: https://api.codeclimate.com/v1/badges/3130fa0ba3b7993fbf0a/maintainability [quality-url]: https://codeclimate.com/github/nalgeon/podsearch-py

Isn't that cool?

d. Task automation

Tox is good, but it's not very convenient for developers. Running a single command (such as pylint,coverage, etc.) is faster. But they are very lengthy, so we automate some meaningless operations.

Let's create a short alias for the frequent operations of Makefile:

.default _ GOAL: = help .PHONY: coverage deps help lint push test coverage: # # Run tests with coverage coverage erase coverage run-- include=podsearch/*-m pytest-ra coverage report-m deps: # # Install dependencies pip install black coverage flake8 mccabe mypy pylint pytest tox lint: # # Lint and static-check flake8 podsearch pylint podsearch mypy podsearch push: # # Push code with tags git push & & git push-- tags test: # # Run tests pytest-ra

Makefile

This is our mission:

$make help Usage: make [task] task help-coverage Run tests with coverage deps Install dependencies lint Lint and static-check push Push code with tags test Run tests help Show help message

To make the code more concise, replace the original build.yml step with the make call:

-name: Install dependencies run: | make deps-name: Run tox run: | make toxE. Cloud release

GitHub has the ability to run flit publish for us. Let's create a separate workflow:

Name: publish on: release: types: [created] jobs: publish: runs-on: ubuntu-latest steps:-name: Checkout sources uses: actions/checkout@v2-name: Set up Python uses: actions/setup-python@v2 with: python-version: | make deps-name: Publish to PyPi env: FLIT_USERNAME: ${secrets.PYPI_USERNAME}} FLIT_PASSWORD: ${{secrets.PYPI_PASSWORD}} run: | make publishpublish.yml |

PYPI_USERNAME and PYPI_PASSWORD are set in the repository settings (Settings > Secrets > New repository secret). Use your PyPi username and password, or even better, the-API token.

Now, once a new version is created, GitHub will automatically release the package.

Your package is ready! It has everything people dream of: clean code, clear documentation, testing and cloud building. It's time to tell your colleagues and friends.

These settings will make your Python package AWESOME:

Pyproject.toml

Tox.ini

Makefile

Build.yml

Publish.yml

This is what the editor shares with you about the correct posture of releasing the Python package in 2021. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.