Package: scikit-hep-repo-review
Scikit-HEP repo-reviewThis tool can check the style of a repository. Use like this:pipxrun'scikit-hep-repo-review[cli]'<pathtorepository>This will produce a list of results - green checkmarks mean this rule is
followed, red x’s mean the rule is not. A yellow warning sign means that the
check was skipped because a previous required check failed. Some checks will
fail, that’s okay - the goal is bring all possible issues to your attention,
not to force compliance with arbitrary checks. Eventually there might be a way
to mark checks as ignored.For example,GH101expects all your action files to have a nicename:field. If you are happy with the file-based names you see in CI, you should
feel free to simply ignore this check (just visually ignore it for the moment,
a way to specify ignored checks will likely be added eventually).All checks are mentioned at least in some way in theScikit-HEP Developer
Guidelines. You should read that first - if you are not attempting to follow
them, some of the checks might not work. For example, the guidelines specify
pytest configuration be placed inpyproject.toml. If you place it somewhere
else, then all the pytest checks will be skipped.You are not required to be in Scikit-HEP to find this useful, however -
examples of repositories that at least partially follow the guidelines includepypa/cibuildwheel,pypa/build, andpybind/pybind11.DevelopmentThis repository is intended to be fun to develop - it requires and uses Python
3.10, and uses a lot of the new features in 3.9 and 3.10. It's maybe not
entirely conventional, but it's fun.There are a few key designs that are very useful and make this possible. First,
all paths are handled as Traversables. This allows a simple Traversable
implementation based onopen_urlto provide a web interface for use in the
webapp. It also would allowzipfile.Pathto work just as well, too - no need
to extract.Checks can request fixtures (like pytest) as arguments. Check files can add new
fixtures as needed. Fixtures are are specified with entry points, and take any
other fixture as arguments as well - thepackagefixture represents the root
of the package you are checking, and is the basis for all other fixtures.
Checks are specified via an entrypoint that returns a dict of checks; this also
can accept fixtures, allowing dynamic check listings.Check files do not depend on the main library, and can be extended (similar to
Flake8). You register new check files via entry-points - so extending this is
with custom checks or custom fixtures is easy and trivial. There's no need to
subclass or do anything with the base library - no dependency required.Checks are as simple as possible so they are easy to write. A check is a class
with the name (1-2 letters + number) and a docstring (the check message). It
should define a set ofrequireswith any checks it depends on (by name), and
have a check classmethod. The docstring of this method is the failure message,
and supports substitution. Arguments to this method are fixtures, andpackageis the built-in one providing the package directory as a Traversable. Any other
fixtures are available by name. A new fixture is given the package Traversable,
and can produce anything; fixtures are topologically sorted, pre-computed and
cached.The runner will topologically sort the checks, and checks that do not run will
get aNoneresult and the check method will not run. The front-end (Rich
powered CLI or Pyodide webapp) will render the markdown-formatted check
docstring only if the result isFalse.LinksThis project inspiredTry-PyHF, an
interface for a High Energy Physics package in Scikit-HEP.This project inspiredabSENSE, an
web interface to abSENSE.