@@ -19,22 +19,25 @@ output formats are supported; `rich`, `svg`, `html`, and `json`.
19
19
20
20
` sp-repo-review ` provides checks based on the
21
21
[ Scientific-Python Development Guide] [ ] at [ scientific-python/cookie] [ ] . A live
22
- WebAssembly demo using ` sp-repo-review ` is
22
+ WebAssembly demo using [ sp-repo-review] [ ] is
23
23
[ here] [ repo-review-demo ] .
24
24
25
25
## Running repo-review
26
26
27
27
Repo-review supports running multiple ways:
28
28
29
- - From the command line on a local folder
29
+ - [ From the command line] [ cli ] on a local folder
30
30
- From the command line on a remote repository on GitHub (` gh:org/repo@branch ` )
31
- - From WebAssembly in [ Pyodide] [ ] (example in ` docs/index.html ` )
31
+ - [ From WebAssembly] [ webapp ] in [ Pyodide] [ ] (example in ` docs/index.html ` )
32
+ - [ From pre-commit] [ intro-pre-commit ]
33
+ - [ From GitHub Actions] [ intro-github-actions ]
34
+ - [ From Python] [ programmatic-usage ]
32
35
33
36
If the root of a package is not the repository root, pass ` --package-dir a/b/c ` .
34
37
35
38
## Configuration
36
39
37
- Repo-review supports configuration via ` pyproject.toml ` :
40
+ Repo-review [ supports configuration] [ intro-configuring ] via ` pyproject.toml ` :
38
41
39
42
``` toml
40
43
[tool .repo-review ]
@@ -67,21 +70,22 @@ This project is intended to be fun and easy to develop and design checks for -
67
70
it requires and uses Python 3.10, and uses a lot of the new features in 3.9 and
68
71
3.10. It's maybe not entirely conventional, but it enables very simple plugin
69
72
development. It works locally, remotely, and in WebAssembly (using
70
- [ Pyodide] [ ] ).
73
+ [ Pyodide] [ ] ). [ See the docs ] [ writing-a-plugin ] .
71
74
72
75
There are a few key designs that are very useful and make this possible. First,
73
76
all paths are handled as Traversables. This allows a simple Traversable
74
77
implementation based on ` open_url ` to provide a web interface for use in the
75
78
webapp. It also would allow ` zipfile.Path ` to work just as well, too - no need
76
79
to extract.
77
80
78
- Checks can request fixtures (like [ pytest] [ ] ) as arguments. Check files can add new
79
- fixtures as needed. Fixtures are are specified with entry points, and take any
80
- other fixture as arguments as well - the ` root ` and ` package ` fixtures
81
- represents the root of the repository and of the package you are checking,
82
- respectively, and are the basis for all other fixtures. ` pyproject ` is provided
83
- as well. Checks are specified via an entrypoint that returns a dict of checks;
84
- this also can accept fixtures, allowing dynamic check listings.
81
+ [ Checks] [ ] can request [ fixtures] [ ] (like [ pytest] [ ] ) as arguments. Check files
82
+ can add new fixtures as needed. Fixtures are are specified with entry points,
83
+ and take any other fixture as arguments as well - the ` root ` and ` package `
84
+ fixtures represents the root of the repository and of the package you are
85
+ checking, respectively, and are the basis for the other fixtures, which are
86
+ topologically sorted and cached. ` pyproject ` is provided as well. Checks are
87
+ specified via an entrypoint that returns a dict of checks; this can also can
88
+ accept fixtures, allowing dynamic check listings.
85
89
86
90
Check files do not depend on the main library, and can be extended (similar to
87
91
Flake8). You register new check files via entry-points - so extending this is
@@ -102,6 +106,16 @@ get a `None` result and the check method will not run. The front-end (Rich
102
106
powered CLI or Pyodide webapp) will render the markdown-formatted check
103
107
docstring only if the result is ` False ` .
104
108
109
+ Checks are organized by [ Families] [ ] . A plugin can customize the display name,
110
+ change the sort order, and add an optional (dynamic) description. Like the other
111
+ collection functions, the family entry-point also supports fixtures.
112
+
113
+ ## Plugins
114
+
115
+ Feel free to request your plugin be added to this list.
116
+
117
+ - [ sp-repo-review] [ ] : Checks based on the [ Scientific-Python Development Guide] [ ] .
118
+
105
119
## Links
106
120
107
121
This project inspired [ Try-PyHF] ( https://kratsg.github.io/try-pyhf/ ) , an
@@ -131,4 +145,18 @@ This was developed for [Scikit-HEP][] before moving to Scientific-Python.
131
145
[ scientific-python/cookie ] : https://github.com/scientific-python/cookie
132
146
[ scikit-hep ] : https://scikit-hep.org
133
147
148
+ [ intro-precommit ] : https://repo-review.readthedocs.io/en/latest/intro.html#pre-commit
149
+ [ intro-github-actions ] : https://repo-review.readthedocs.io/en/latest/intro.html#github-actions
150
+ [ cli ] : https://repo-review.readthedocs.io/en/latest/cli.html
151
+ [ programmatic-usage ] : https://repo-review.readthedocs.io/en/latest/programmatic.html
152
+ [ webapp ] : https://repo-review.readthedocs.io/en/latest/webapp.html
153
+ [ intro-configuring ] : https://repo-review.readthedocs.io/en/latest/intro.html#configuring
154
+ [ writing-a-plugin ] : https://repo-review.readthedocs.io/en/latest/plugins.html
155
+ [ fixtures ] : https://repo-review.readthedocs.io/en/latest/fixtures.html
156
+ [ checks ] : https://repo-review.readthedocs.io/en/latest/checks.html
157
+ [ families ] : https://repo-review.readthedocs.io/en/latest/families.html
158
+ [ changelog ] : https://repo-review.readthedocs.io/en/latest/changelog.html
159
+ [ api ] : https://repo-review.readthedocs.io/en/latest/api/repo_review.html
160
+
161
+
134
162
<!-- prettier-ignore-end -->
0 commit comments