Introduction

aazgbtr32# Contributing

Please don't be shy - comment, discuss and suggest whatever you think is important in the discussions on github, if you notice a bug please describe it in issues, and if you decide to contribute to the development of the project, feel free to send pull request, and if possible, read further during development this section.

When developing, modifying and fixing a feature, please fill in and correct all annotations and docstrings in the code, and also try, if possible, to fill in / supplement the description of the functionality and its use in the section of the documentation, also add tests for new or fixed functionality, read more below:

Environment

To work, you need a configured environment, for this there is the following script:

$ hatch run init

Note

All development is done using hatch. To work with it, you will need to install it globally, I advise you to do this using pipx.

This script will completely configure the environment - configure gitflow, connect git hooks, and install and configure a virtual environment, to run python in this environment, run the following command:

$ hatch run ipython

Git flow

As you develop and refine, please try to keep your repository consistent with gitflow.

Question

Probably this point will change, the library is actively developed, I took this approach as a familiar one, however, I think that it will need to be changed. If you have any suggestions I'll be happy to listen.

Internationalization

To add translations there are two useful commands:

makemessages

This is a wrapper around the makemessages django command and creates/updates localization files in each meringue application.

$ hatch run makemessages

compilemessages

This is a wrapper around the compilemessages django command and compiles all translations.

$ hatch run compilemessages

Tests

When working on a project, it is extremely important to cover everything with tests in order to avoid problems and errors in the code. See working on tests in the appropriate section.

Documentation

The documentation is implemented using the mkdocs generator and the mkdocs material theme. When working on library functionality, two main sections usage and reference are important. For more information about developing documentation, see the corresponding section.

Versioning

To update the version, use hatch version

show current version:

$ hatch version
1.0.0a0

update patch and beta version from 1.0.0a0 to 1.0.1b0

$ hatch version patch,beta
Old: 1.0.0a0
New: 1.0.1b0

Commit message convention

To write a commit, we adhere to the Conventional Commits specification, as well as gitmoji as a special case of conventional commits. You can use gitmoji-cli for this process. This is necessary for the automatic generation of the changelog.

Info

The list of emoji needs to be improved, now it is bloated and there are controversial points like which means deleting the code...

Changelog generation

To generate the changelog, the gitmoji-changelog utility is used as part of the command:

$ hatch run changelog-update

All tags will be pulled from the repository, and a changelog will be generated based on the commits.

Building and publishing

For the build, hatch is used and to build the library there is the following command:

$ hatch build

This command is provided by hatch and for more details on how it works, it is better to look at the hatch documentation.

The build and upload of releases is implemented in GitHub Actions and occurs automatically when pushing release tags like v*.

More details on how to set up a build and upload can be found in the workflow config.

Authors: Dmitry Dobrynin

---