Add pre-commit.ci

[mikemhenry]

We can use this PR to decide what pre-commit hooks we want to use with pre-commit.ci

https://pre-commit.ci/
https://pre-commit.com/
https://pre-commit.com/hooks.html

I am not too fused on which tools we use but I would like to have things that:

• auto format code
• clean up files (like removing trailing whitespace)
• prevent people from making git mistakes (large files, broken symlinks, etc)

@dotsdl @ianmkenney @IAlibay @atravitz -- Interested in hearing your thoughts!

[mikemhenry]

Related #291 #363

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.66%. Comparing base (d27100a) to head (3176437).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #384   +/-   ##
=======================================
  Coverage   98.66%   98.66%           
=======================================
  Files          36       36           
  Lines        2097     2097           
=======================================
  Hits         2069     2069           
  Misses         28       28           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[IAlibay]

I know it's possible with black to choose a "standard", is this the way we do this or does this just control the version of black we install?

[ianmkenney]

I'm also a bit curious here. Which tool is responsible for installing what? For instance, with black, does running the pre-commit install actually install black or just the hook that will execute black?

[mikemhenry]

Good question! So if you are just using pre-commit.ci, locally you don't need to do anything. But if you use this locally, pre-commit when running for the first time will create a virtual python environment (separate than whatever one you are currently using, this lets you use packages and versions that might not work with your program be used for the pre-commit hooks) and install everything needed for the hooks and run them. When you re-run the hooks, it will re-use the virtual environment it created the first time.

so tl;dr if you install pre-commit, it will create a virtual env that will install all the tools needed, then execute the hooks

[mikemhenry]

Also as a quick follow up, there is a section in the pyproject.toml:

[tool.black]
line-length = 120 

that controls black's config, so we can set it to use whichever "standard" we want.

[ianmkenney]

I think overall this looks good, but I have a couple of questions/requests

[ianmkenney]

How would this handle functions where a docstring might be overkill? Specifically, I'm thinking of closures, which usually don't have docstrings. Since closures can be named I find that using them can improve code readability, but adding docstrings to them feels redundant. Would interrogate mark these as lacking documentation?

[mikemhenry]

The config is controlled in the pyproject.toml (so that way if you run the tool as a standalone thing, you use the same config as the one that runs on pre-commit)

[tool.interrogate]
fail-under = 0 
ignore-regex = ["^get$", "^mock_.*", ".*BaseClass.*"]
# possible values for verbose: 0 (minimal output), 1 (-v), 2 (-vv)
verbose = 2 
color = true
exclude = ["build", "docs"]

Config options are listed here: https://github.com/econchick/interrogate?tab=readme-ov-file#configuration

I don't want the tools to get in our way, so if we find it too annoying and gives us many false positives, we can drop it.

[mikemhenry]

Working on this today! Thanks for the feedback everyone!

[mikemhenry]

@IAlibay @ianmkenney - This is ready for another look!
@atravitz - Let me know what you think! I also know you were looking at ruff which might be able to replace black and isort and add stuff like check for unused imports and the like.

[ianmkenney]

This looks good to me! Thanks for putting this together.

[mikemhenry]

I want to wait for others to provide some feedback, but we can discuss next steps.

Do we want to just merge this in and fix things as we go on PRs? Or do we want to also run the hooks on the files as part of this PR or a separate PR?

[ianmkenney]

@mikemhenry cleaner to run it here once we're happy with the tooling choices

[dotsdl]

@mikemhenry please proceed with merge and setup of pre-commit CI. After this, we'll want to immediately apply the reformatting to gufe.

@atravitz also recommends we tell git blame to ignore the commit in which we applied the reformatting in order to maintain the usefulness of git blame; see here for details: https://www.stefanjudis.com/today-i-learned/how-to-exclude-commits-from-git-blame/

[mikemhenry]

@mikemhenry cleaner to run it here once we're happy with the tooling choices

@mikemhenry please proceed with merge and setup of pre-commit CI. After this, we'll want to immediately apply the reformatting to gufe.

@IAlibay @atravitz -- can you break the tie here?

[ianmkenney]

@mikemhenry cleaner to run it here once we're happy with the tooling choices

@mikemhenry please proceed with merge and setup of pre-commit CI. After this, we'll want to immediately apply the reformatting to gufe.

@IAlibay @atravitz -- can you break the tie here?

@mikemhenry I'll break it---go with David!

[mikemhenry]

Cool, I will do the formatting in a separate PR but wait until that is done to merge in this PR so there isn't a gap between having .pre-commit going and everything unformatted

[mikemhenry]

Also need to add https://pre-commit.ci/#configuration-autofix_prs !!

[mikemhenry]

I added a pull request template that mentions how to run the pre-commit.ci

[mikemhenry]

Okay so plan is to merge in #421 if it is green. Then I will add the commit from that merge to .git-blame-ignore-revs which I will add to this PR. That way we will have a functional git history, and this PR will correctly point to "me" as the blame for the config + the ignore recs, which will be helpful for who ever looks at this in the future