diff --git a/azure-pipelines.yml b/azure-pipelines.yml index 31baf41ff4cb1..83dbc83365319 100644 --- a/azure-pipelines.yml +++ b/azure-pipelines.yml @@ -45,8 +45,12 @@ jobs: versionSpec: '3.9' - bash: | # Include pytest compatibility with mypy - pip install pytest flake8 mypy==0.782 + pip install pytest flake8 mypy==0.782 black==21.6b0 displayName: Install linters + - bash: | + # Remove comment when code is formatted by black + # black --check . + displayName: Run black - bash: | ./build_tools/circle/linting.sh displayName: Run linting diff --git a/doc/developers/contributing.rst b/doc/developers/contributing.rst index 359dd80a09f4c..690880133805d 100644 --- a/doc/developers/contributing.rst +++ b/doc/developers/contributing.rst @@ -261,7 +261,7 @@ how to set up your git repository: .. prompt:: bash $ - pip install cython pytest pytest-cov flake8 mypy + pip install cython pytest pytest-cov flake8 mypy black==21.6b0 5. Install scikit-learn in editable mode: @@ -433,7 +433,17 @@ complies with the following rules before marking a PR as ``[MRG]``. The non-regression tests should fail for the code base in the ``main`` branch and pass for the PR code. -5. **Make sure that your PR does not add PEP8 violations**. To check the +5. Run `black` to auto-format your code. + + .. prompt:: bash $ + + black . + + See black's + `editor integration documentation `_ + to configure your editor to run `black`. + +6. **Make sure that your PR does not add PEP8 violations**. To check the code that you changed, you can run the following command (see :ref:`above ` to set up the ``upstream`` remote): @@ -443,14 +453,14 @@ complies with the following rules before marking a PR as ``[MRG]``. The or `make flake8-diff` which should work on unix-like system. -6. Follow the :ref:`coding-guidelines`. +7. Follow the :ref:`coding-guidelines`. -7. When applicable, use the validation tools and scripts in the +8. When applicable, use the validation tools and scripts in the ``sklearn.utils`` submodule. A list of utility routines available for developers can be found in the :ref:`developers-utils` page. -8. Often pull requests resolve one or more other issues (or pull requests). +9. Often pull requests resolve one or more other issues (or pull requests). If merging your pull request means that some other issues/PRs should be closed, you should `use keywords to create link to them `_ @@ -460,23 +470,23 @@ complies with the following rules before marking a PR as ``[MRG]``. The related to some other issues/PRs, create a link to them without using the keywords (e.g., ``See also #1234``). -9. PRs should often substantiate the change, through benchmarks of - performance and efficiency (see :ref:`monitoring_performances`) or through - examples of usage. Examples also illustrate the features and intricacies of - the library to users. Have a look at other examples in the `examples/ - `_ - directory for reference. Examples should demonstrate why the new - functionality is useful in practice and, if possible, compare it to other - methods available in scikit-learn. +10. PRs should often substantiate the change, through benchmarks of + performance and efficiency (see :ref:`monitoring_performances`) or through + examples of usage. Examples also illustrate the features and intricacies of + the library to users. Have a look at other examples in the `examples/ + `_ + directory for reference. Examples should demonstrate why the new + functionality is useful in practice and, if possible, compare it to other + methods available in scikit-learn. -10. New features have some maintenance overhead. We expect PR authors +11. New features have some maintenance overhead. We expect PR authors to take part in the maintenance for the code they submit, at least initially. New features need to be illustrated with narrative documentation in the user guide, with small code snippets. If relevant, please also add references in the literature, with PDF links when possible. -11. The user guide should also include expected time and space complexity +12. The user guide should also include expected time and space complexity of the algorithm and scalability, e.g. "this algorithm can scale to a large number of samples > 100000, but does not scale in dimensionality: n_features is expected to be lower than 100". @@ -1357,3 +1367,13 @@ make this task easier and faster (in no particular order). `_) is also extremely useful to see every occurrence of a pattern (e.g. a function call or a variable) in the code base. + +- Configure `git blame` to ignore the commit that migrated the code style to + `black`. + + .. prompt:: bash $ + + git config blame.ignoreRevsFile .git-blame-ignore-revs + + Find out more information in black's + `documentation for avoiding ruining git blame `_. diff --git a/pyproject.toml b/pyproject.toml index 30d2e124e2c9f..613d53e25d295 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -20,24 +20,17 @@ requires = [ [tool.black] line-length = 88 exclude = ''' - -( - /( - \.eggs # exclude a few common directories in the - | \.git # root of the project - | \.mypy_cache - | examples - | build - | dist - | doc - | sklearn/externals - )/ -) -''' -include = ''' -( - /( - doc/conf.py - )/ -) +/( + \.eggs # exclude a few common directories in the + | \.git # root of the project + | \.mypy_cache + | examples + | build + | dist + | doc/tutorial + | doc/_build + | doc/auto_examples + | sklearn/externals + | asv_benchmarks/env +)/ ''' diff --git a/sklearn/_min_dependencies.py b/sklearn/_min_dependencies.py index 5f44db8c7276b..09661e6038977 100644 --- a/sklearn/_min_dependencies.py +++ b/sklearn/_min_dependencies.py @@ -33,6 +33,7 @@ 'pytest': (PYTEST_MIN_VERSION, 'tests'), 'pytest-cov': ('2.9.0', 'tests'), 'flake8': ('3.8.2', 'tests'), + 'black': ('21.6b0', 'tests'), 'mypy': ('0.770', 'tests'), 'pyamg': ('4.0.0', 'tests'), 'sphinx': ('4.0.1', 'docs'),