Add linting

.github/workflows/github-ci.yml

@@ -29,6 +29,14 @@ jobs:
           pip install -r requirements.txt
           pip install scipy
 
+      # Lint: black and flake8
+      - name: Install lint dependencies
+        run: pip install .[lint]
+      - name: Run black (check only)
+        run: black --check .
+      - name: Run flake8
+        run: flake8 .
+
       # find and run all unit tests
       - name: Run unit tests
         run: python -m unittest discover test

.pre-commit-config.yaml

@@ -0,0 +1,22 @@
+repos:
+  - repo: https://github.com/psf/black
+    rev: 24.4.2  # Use the latest stable version or pin as needed
+    hooks:
+      - id: black
+        language_version: python3
+        exclude: '(^|/)(README\.md|.*\.svg|.*\.html)$'
+        args: ["--line-length=120", "--target-version=py38"]
+  - repo: https://github.com/pycqa/flake8
+    rev: 7.0.0  # Use the latest stable version or pin as needed
+    hooks:
+      - id: flake8
+        language_version: python3
+        exclude: '(^|/)(README\.md|.*\.svg|.*\.html)$'
+        args: ["--max-line-length=120", "--extend-ignore=E203,W503"]
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.5.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+      - id: check-added-large-files

CONTRIBUTING.md

@@ -1,65 +1,65 @@
 # Contributing to svgpathtools
 
-The following is a few and guidelines regarding the current philosophy, style, 
-flaws, and the future directions of svgpathtools.  These guidelines are meant 
+The following is a few and guidelines regarding the current philosophy, style,
+flaws, and the future directions of svgpathtools.  These guidelines are meant
 to make it easy to contribute.
 
 ## Being a Hero
-We need better automated testing coverage.  Please, submit unittests!  See the 
+We need better automated testing coverage.  Please, submit unittests!  See the
 Testing Style section below for info.
 
 Here's a list of things that need (more) unittests:
 * TBA (feel free to help)
 
 ## Submitting Bugs
-If you find a bug, please submit an issue along with an **easily reproducible 
+If you find a bug, please submit an issue along with an **easily reproducible
 example**.  Feel free to make a pull-request too (see relevant section below).
 
 
-## Submitting Pull-Requests 
+## Submitting Pull-Requests
 
 #### New features come with unittests and docstrings.
-If you want to add a cool/useful feature to svgpathtools, that's great!  Just 
-make sure your pull-request includes both thorough unittests and well-written 
-docstrings.  See relevant sections below on "Testing Style" and 
+If you want to add a cool/useful feature to svgpathtools, that's great!  Just
+make sure your pull-request includes both thorough unittests and well-written
+docstrings.  See relevant sections below on "Testing Style" and
 "Docstring Style" below.
 
 
 #### Modifications to old code may require additional unittests.
-Certain submodules of svgpathtools are poorly covered by the current set of 
-unittests.  That said, most functionality in svgpathtools has been tested quite 
+Certain submodules of svgpathtools are poorly covered by the current set of
+unittests.  That said, most functionality in svgpathtools has been tested quite
 a bit through use.
-The point being, if you're working on functionality not currently covered by 
-unittests (and your changes replace more than a few lines), then please include 
+The point being, if you're working on functionality not currently covered by
+unittests (and your changes replace more than a few lines), then please include
 unittests designed to verify that any affected functionary still works.
 
 
-## Style 
+## Style
 
 ### Coding Style
-* Follow the PEP8 guidelines unless you have good reason to violate them (e.g. 
-you want your code's variable names to match some official documentation, or 
+* Follow the PEP8 guidelines unless you have good reason to violate them (e.g.
+you want your code's variable names to match some official documentation, or
 PEP8 guidelines contradict those present in this document).
-* Include docstrings and in-line comments where appropriate.  See 
+* Include docstrings and in-line comments where appropriate.  See
 "Docstring Style" section below for more info.
-* Use explicit, uncontracted names (e.g. `parse_transform` instead of 
-`parse_trafo`).   Maybe the most important feature for a name is how easy it is 
+* Use explicit, uncontracted names (e.g. `parse_transform` instead of
+`parse_trafo`).   Maybe the most important feature for a name is how easy it is
 for a user to guess (after having seen other names used in `svgpathtools`).
-* Use a capital 'T' denote a Path object's parameter, use a lower case 't' to 
-denote a Path segment's parameter.  See the methods `Path.t2T` and `Path.T2t` 
-if you're unsure what I mean.  In the ambiguous case, use either 't' or another 
-appropriate option (e.g. "tau"). 
+* Use a capital 'T' denote a Path object's parameter, use a lower case 't' to
+denote a Path segment's parameter.  See the methods `Path.t2T` and `Path.T2t`
+if you're unsure what I mean.  In the ambiguous case, use either 't' or another
+appropriate option (e.g. "tau").
 
 
 ### Testing Style
-You want to submit unittests?!  Yes!  Please see the svgpathtools/test folder 
+You want to submit unittests?!  Yes!  Please see the svgpathtools/test folder
 for examples.
 
 
 ### Docstring Style
-All docstrings in svgpathtools should (roughly) adhere to the Google Python 
-Style Guide.  Currently, this is not the case... but for the sake of 
-consistency, Google Style is the officially preferred docstring style of 
-svgpathtools.  
+All docstrings in svgpathtools should (roughly) adhere to the Google Python
+Style Guide.  Currently, this is not the case... but for the sake of
+consistency, Google Style is the officially preferred docstring style of
+svgpathtools.
 [Some nice examples of Google Python Style docstrings](
 https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html)

LICENSE.txt

@@ -18,4 +18,4 @@ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+SOFTWARE.

LICENSE2.txt

@@ -18,4 +18,4 @@ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+SOFTWARE.

MANIFEST.in

@@ -1,2 +1,2 @@
 include *.svg LICENSE*
-recursive-include test *.svg
+recursive-include test *.svg