How to open source your Python library

This article mainly introduces how to open source your Python library, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let Xiaobian take you to understand.

1. Source code

Put the code on GitHub, where there are many open source projects, and it's easy for people to submit pull requests.

2. License

Select an open source license. Generally speaking, the MIT license is a good tolerant license. If you have specific requirements, Creative Common's selection license can guide you through other options. Most importantly, there are three rules to keep in mind when selecting licenses:

Do not create your own license.

Do not create your own license.

Do not create your own license.

3 、 README

Place a file named README.rst (formatted using ReStructured Text) at the top of the project tree.

GitHub will render ReStructured Text like Markdown, while ReST will perform better in Python's document ecosystem.

4. Test

Write tests. It's of no use to you. But it's very useful for people who want to write patches that don't break the functionality.

Testing helps collaborators collaborate.

In general, if you can run it with pytest, it will. There are other testing tools-but there is little reason to use them.

5. Style

Styling using linter: PyLint, Flake8, or Black with-- check. Unless you use Black, be sure to specify configuration options in a file and check in to the version control system.

6. API documents

Use docstrings to record modules, functions, classes, and methods.

You can use several styles. I prefer Google-style docstrings, but ReST docstrings is also an option.

Sphinx can handle both Google style and ReST's docstrings to integrate fragmented documents into API documents.

7. Scattered documents

Use Sphinx. Read our article. Tutorials are useful, but it is also important to specify what this is, what benefits it has, what disadvantages it has, and any special considerations.

8. Build

Use tox or nox to run tests and linter automatically, and build documentation. These tools support "dependency matrices". These matrices tend to grow rapidly, but you can try to test against reasonable samples, such as Python versions, dependency versions, and optional dependencies that may be installed.

9. Packing

Use the setuptools tool. Write a setup.py and a setup.cfg. If both Python 2 and 3 are supported, specify wheel in universal format in setup.cfg.

One of the things tox or nox should do is build wheel and test the installed wheel.

Avoid using C extensions. If you must need them for performance or binding reasons, put them in a separate package. Correctly package the C extension to write a new article. There are a lot of questions here!

10. Continuous integration

Use public persistence tools. TravisCI and CircleCI offer free packages for open source projects. Configure GitHub or other repositories to pass checks before merging pull requests, so you don't have to worry about telling users to fix tests or styles in code reviews.

11. Version

Use SemVer or CalVer. There are many tools that can help you manage versions: incremental, bumpversion, and setuptools_scm are packages on PyPI that can help you manage versions.

12. Release

Publish by running tox or nox and uploading files to PyPI using twine. You can do this by "testing upload" in DevPI.

Thank you for reading this article carefully. I hope the article "how to Open Source your Python Library" shared by the editor will be helpful to everyone. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!