How to contribute¶
Tutorials¶
If you want to start working on this project, you will need to get familiar with these APIs:
It is also recommended to take a look at these resources:
Visual tool to explore python’s ast (very useful!)
Missing
ast
guideList of
python
static analysis toolsList of
flake8
extensions
Developer’s documentation¶
Make sure that you are familiar with developer’s documentation.
That’s a main starting point to the future development. You can jump start into the development of new rules by reading “Creating a new rule tutorial”.
Dependencies¶
We use poetry to manage the dependencies.
To install them you would need to run install
command:
poetry install
To activate your virtualenv
run poetry shell
.
Adding new flake8 plugins¶
If you are adding a flake8
plugin dependency (not dev-dependency),
you will have to do several things:
Install plugin with
poetry
Add docs about the error code to the
errors/index.rst
Add a test that the plugin is working to
tests/test_plugins.py
Tests¶
We use pytest
and flake8
for quality control.
We also use wemake_python_styleguide
itself
to develop wemake_python_styleguide
.
To run all tests:
pytest
To run linting:
flake8 .
These steps are mandatory during the CI.
Architecture¶
We use layer-lint to enforce strict layered architecture.
layer-lint wemake_python_styleguide
All contracts must be valid for each commit. This step is mandatory during the CI.
Type checks¶
We use mypy
to run type checks on our code.
To use it:
mypy wemake_python_styleguide
This step is mandatory during the CI.
Submitting your code¶
We use trunk based
development (we also sometimes call it wemake-git-flow
).
What the point of this method?
We use protected
master
branch, so the only way to push your code is via pull requestWe use issue branches: to implement a new feature or to fix a bug create a new branch named
issue-$TASKNUMBER
Then create a pull request to
master
branchWe use
git tag
s to make releases, so we can track what has changed since the latest release
So, this way we achieve an easy and scalable development process which frees us from merging hell and long-living branches.
In this method, the latest version of the app is always in the master
branch.
Making patches to older versions¶
If you want to release a patch for an older version, that what you have to do:
Check out the previous
git tag
Create a new branch relative to this tag
Merge it into master, there might be some
rebase
andcherry-pick
involved during this operation
Before submitting¶
Before submitting your code please do the following steps:
Run
pytest
to make sure everything was working beforeAdd any changes you want
Add tests for the new changes
Add an integration test into
tests/fixtures/noqa.py
Edit documentation if you have changed something significant
Update
CHANGELOG.md
with a quick summary of your changesRun
pytest
again to make sure it is still workingRun
mypy
to ensure that types are correctRun
flake8
to ensure that style is correctRun
layer-lint
to ensure that architecture contracts are correctRun
doc8
to ensure that docs are correct
Other help¶
You can contribute by spreading a word about this library. It would also be a huge contribution to write a short article on how you are using this project. You can also share your best practices with us.