If you want to start working on this project, you will need to get familiar with these APIs:
- Writing a
flake8
plugin - Using
ast
module - Tokenizer for Python source
- Tokens tutorial
It is also recommended to take a look at these resources:
- Visual tool to explore python's ast (very useful, but outdated!)
- Missing
ast
guide - List of
python
static analysis tools - List of
flake8
extensions
- Fork our repo, here's the guide on forking
- Clone your new repo (forked repo) to have a local copy of the code
- Apply the required changes! See developer docs on how to work with the code
- Send a Pull Request to our original repo. Here's the helpful guide on how to do that
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".
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
.
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
pages/usage/violations/index.rst
- Add a test that the plugin is working to
tests/test_plugins.py
Run make test
to run everything we have!
- Building directly in Windows does not work.
- Instead, use a Windows Subsystem for Linux (WSL) such as Ubuntu 18.04 LTS that you can get from the Microsoft Store.
- Clone the project to a part of the WSL where Windows does not overwrite permissions, for example directly to the home of the WSL (do
cd
and thengit clone
). That problem looks like this and you can read more about why changing the permissions does not work here.
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.
We use import-linter to enforce strict layered architecture.
lint-imports
See .importlinter
file for contracts definition.
All contracts must be valid for each commit.
This step is mandatory during the CI.
We use mypy
to run type checks on our code.
To use it:
mypy wemake_python_styleguide
This step is mandatory during the CI.
This project is developed by a diverse and multilingual group of people. Many of us are not English native speakers and we also know that people can make mistakes and typos even in the simplest of words.
So, that's why we use a bunch of tools to find and fix spelling and grammar.
You will need to install them manually, because we don't ship them with the dependencies:
pip install codespell flake8-spellcheck
And then you can use them:
# codespell:
codespell -w wemake_python_styleguide tests docs scripts styles *.md
# flake8-spellcheck:
flake8 --whitelist ./tests/whitelist.txt .
We run them from time to time, this is not in the CI yet.
We also have several helpers to make your development work easier:
astboom
is used to visualizeast
nodes in other python modules, usage:astboom ast < my_module.py
tokelor
is used to visualize tokens in other python modules, usage:tokelor my_module.py
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 request - We 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
branch - We 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.
Before submitting your code please do the following steps:
- Run
pytest
to make sure everything was working before - Add 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 changes - Run
pytest
again to make sure it is still working - Run
mypy
to ensure that types are correct - Run
flake8
to ensure that style is correct - Run
lint-imports
to ensure that architecture contracts are correct - Run
doc8
to ensure that docs are correct
You can run everything at once with make test
,
see our Makefile
for more details.
This section is intended for maintainers only. If you are not a maintainer (or do not know what it means), just skip it. You are not going to miss anything useful.
Releasing a new version requires several steps:
- Ensure that
CHANGELOG.md
is up-to-date and contains all changes - Bump version in
pyproject.toml
- Bump version in
Dockerfile
that is used for Github Action - Run
git commit -a -m 'Version x.y.z release' && git tag -a x.y.x -m 'Version x.y.z' && git push && git push --tags
- Run
poetry publish --build
- Edit Github Release and mark that new action version is released
Done! New version is released.
If you want to release a patch for an older version, that what you have to do:
- Check out the previous
tag
- Create a new branch relative to this tag:
git checkout $TAG_NAME; git checkout -b $RELEASE_NAME
- Merge it into master, there might be some
rebase
andcherry-pick
involved during this operation
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.
You can also consider donations to the project:
- https://opencollective.com/wemake-python-styleguide
- https://issuehunt.io/r/wemake-services/wemake-python-styleguide
Number of current supporters:
Here are the awesome people who contributed to our project: