mirror of
https://github.com/google/bumble.git
synced 2026-05-02 02:58:02 +00:00
formatting and linting automation
Squashed commits: [cd479ba] formatting and linting automation [7fbfabb] formatting and linting automation [c4f9505] fix after rebase [f506ad4] rename job [441d517] update doc (+7 squashed commits) [2e1b416] fix invoke and github action [6ae5bb4] doc for git blame [44b5461] add GitHub action [b07474f] add docs [4cd9a6f] more linter fixes [db71901] wip [540dc88] wip
This commit is contained in:
43
docs/mkdocs/src/development/code_style.md
Normal file
43
docs/mkdocs/src/development/code_style.md
Normal file
@@ -0,0 +1,43 @@
|
||||
CODE STYLE
|
||||
==========
|
||||
|
||||
The Python code style used in this project follows the [Black code style](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html).
|
||||
|
||||
# Formatting
|
||||
|
||||
For now, we are configuring the `black` formatter with the option to leave quotes unchanged.
|
||||
The preferred quote style is single quotes, which isn't a configurable option for `Black`, so we are not enforcing it. This may change in the future.
|
||||
|
||||
## Ignoring Commit for Git Blame
|
||||
|
||||
The adoption of `Black` as a formatter came in late in the project, with already a large code base. As a result, a large number of files were changed in a single commit, which gets in the way of tracing authorship with `git blame`. The file `git-blame-ignore-revs` contains the commit hash of when that mass-formatting event occurred, which you can use to skip it in a `git blame` analysis:
|
||||
|
||||
!!! example "Ignoring a commit with `git blame`"
|
||||
```
|
||||
$ git blame --ignore-revs-file .git-blame-ignore-revs
|
||||
```
|
||||
|
||||
# Linting
|
||||
|
||||
The project includes a `pylint` configuration (see the `pyproject.toml` file for details).
|
||||
The `pre-commit` checks only enforce that there are no errors. But we strongly recommend that you run the linter with warnings enabled at least, and possibly the "Refactor" ('R') and "Convention" ('C') categories as well.
|
||||
To run the linter, use the `project.lint` invoke command.
|
||||
|
||||
!!! example "Running the linter with default options"
|
||||
With the default settings, Errors and Warnings are enabled, but Refactor and Convention categories are not.
|
||||
```
|
||||
$ invoke project.lint
|
||||
```
|
||||
|
||||
!!! example "Running the linter with all categories"
|
||||
```
|
||||
$ invoke project.lint --disable=""
|
||||
```
|
||||
|
||||
# Editor/IDE Integration
|
||||
|
||||
## Visual Studio Code
|
||||
|
||||
The project includes a `.vscode/settings.json` file that specifies the `black` formatter and enables an editor ruler at 88 columns.
|
||||
You may want to configure your own environment to "format on save" with `black` if you find that useful. We are not making that choice at the workspace level.
|
||||
|
||||
11
docs/mkdocs/src/development/contributing.md
Normal file
11
docs/mkdocs/src/development/contributing.md
Normal file
@@ -0,0 +1,11 @@
|
||||
CONTRIBUTING TO THE PROJECT
|
||||
===========================
|
||||
|
||||
To contribute some code to the project, you will need to submit a GitHub Pull Request (a.k.a PR). Please familiarize yourself with how that works (see [GitHub Pull Requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests))
|
||||
|
||||
You should follow the project's [code style](code_style.md), and pre-check your code before submitting a PR. The GitHub project is set up with some [Actions](https://github.com/features/actions) that will check that a PR passes at least the basic tests and complies with the coding style, but it is still recommended to check that for yourself before submitting a PR.
|
||||
To run the basic checks (essentially: running the tests, the linter, and the formatter), use the `project.pre-commit` `invoke` command, and address any issues found:
|
||||
|
||||
```
|
||||
$ invoke project.pre-commit
|
||||
```
|
||||
@@ -1,11 +1,11 @@
|
||||
PYTHON ENVIRONMENTS
|
||||
===================
|
||||
|
||||
When you don't want to install Bumble in your main/default python environment,
|
||||
When you don't want to install Bumble in your main/default python environment,
|
||||
using a virtual environment, where the package and its dependencies can be
|
||||
installed, isolated from the rest, may be useful.
|
||||
|
||||
There are many flavors of python environments and dependency managers.
|
||||
There are many flavors of python environments and dependency managers.
|
||||
This page describes a few of the most common ones.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ Visit the [`venv` documentation](https://docs.python.org/3/library/venv.html) pa
|
||||
|
||||
## Pyenv
|
||||
|
||||
`pyenv` lets you easily switch between multiple versions of Python. It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.
|
||||
`pyenv` lets you easily switch between multiple versions of Python. It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.
|
||||
Visit the [`pyenv` site](https://github.com/pyenv/pyenv) for instructions on how to install
|
||||
and use `pyenv`
|
||||
|
||||
@@ -25,10 +25,10 @@ and use `pyenv`
|
||||
Conda is a convenient package manager and virtual environment.
|
||||
The file `environment.yml` is a Conda environment file that you can use to create
|
||||
a new Conda environment. Once created, you can simply activate this environment when
|
||||
working with Bumble.
|
||||
working with Bumble.
|
||||
Visit the [Conda site](https://docs.conda.io/en/latest/) for instructions on how to install
|
||||
and use Conda.
|
||||
A few useful commands:
|
||||
A few useful commands:
|
||||
|
||||
### Create a new `bumble` Conda environment
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user