You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildstream.apache.org by ro...@apache.org on 2020/12/29 13:30:17 UTC

[buildstream] 06/08: doc/source/hacking: Remove pycodestyle, add Black

This is an automated email from the ASF dual-hosted git repository.

root pushed a commit to branch frazer/flake8
in repository https://gitbox.apache.org/repos/asf/buildstream.git

commit f6aed04e057f20e573844a03d14dba3c7b3942b4
Author: Chandan Singh <cs...@bloomberg.net>
AuthorDate: Mon Nov 11 17:17:05 2019 +0000

    doc/source/hacking: Remove pycodestyle, add Black
    
    Now that code formatting is managed by Black, and we don't need to run
    `pycodestyle` separately, remove corresponding mentions from hacking
    documentation.
    
    Add documentation on how to run Black.
    
    Move out linting and formatting into a separate section for better
    readability.
---
 doc/source/hacking/coding_guidelines.rst   |  6 ++---
 doc/source/hacking/using_the_testsuite.rst | 36 +++++++++++++++++++-----------
 2 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/doc/source/hacking/coding_guidelines.rst b/doc/source/hacking/coding_guidelines.rst
index 7088fc3..4ba6360 100644
--- a/doc/source/hacking/coding_guidelines.rst
+++ b/doc/source/hacking/coding_guidelines.rst
@@ -19,10 +19,10 @@ Approximate PEP-8 Style
 ~~~~~~~~~~~~~~~~~~~~~~~
 Python coding style for BuildStream is approximately `pep8 <https://www.python.org/dev/peps/pep-0008/>`_.
 
-We have a couple of minor exceptions to this standard, we dont want to compromise
-code readability by being overly restrictive on line length for instance.
+The coding style is automatically enforced by `black <https://black.readthedocs.io/en/stable/>`_.
 
-The pep8 linter will run automatically when :ref:`running the test suite <contributing_testing>`.
+Formatting will be checked automatically when running the testsuite on CI. For
+details on how to format your code locally, see :ref:`formatting code <contributing_formatting_code>`.
 
 
 Line lengths
diff --git a/doc/source/hacking/using_the_testsuite.rst b/doc/source/hacking/using_the_testsuite.rst
index 2bd2696..0e476c7 100644
--- a/doc/source/hacking/using_the_testsuite.rst
+++ b/doc/source/hacking/using_the_testsuite.rst
@@ -54,18 +54,6 @@ the same arguments you would give `tox`::
 
   detox -e lint,py36,py37
 
-Linting is performed separately from testing. In order to run the linting step which
-consists of running the ``pycodestyle`` and ``pylint`` tools, run the following::
-
-  tox -e lint
-
-.. tip::
-
-   The project specific pylint and pycodestyle configurations are stored in the
-   toplevel buildstream directory in the ``.pylintrc`` file and ``setup.cfg`` files
-   respectively. These configurations can be interesting to use with IDEs and
-   other developer tooling.
-
 The output of all failing tests will always be printed in the summary, but
 if you want to observe the stdout and stderr generated by a passing test,
 you can pass the ``-s`` option to pytest as such::
@@ -155,9 +143,31 @@ can run ``tox`` with ``-r`` or  ``--recreate`` option.
    tests::
 
      tox -e venv -- <your command(s) here>
-     
+
    Any commands after ``--`` will be run a virtualenv managed by tox.
 
+Running linters
+~~~~~~~~~~~~~~~
+Linting is performed separately from testing. In order to run the linting step which
+consists of running the ``pylint`` tool, run the following::
+
+  tox -e lint
+
+.. tip::
+
+   The project specific pylint configuration is stored in the toplevel
+   buildstream directory in the ``.pylintrc`` file. This configuration can be
+   interesting to use with IDEs and other developer tooling.
+
+.. _contributing_formatting_code:
+
+Formatting code
+~~~~~~~~~~~~~~~
+Similar to linting, code formatting is also done via a ``tox`` environment. To
+format the code using the ``black`` tool, run the following::
+
+   tox -e format
+
 Observing coverage
 ~~~~~~~~~~~~~~~~~~
 Once you have run the tests using `tox` (or `detox`), some coverage reports will