-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pre-commit hooks for Cookbooks? #119
Comments
Maybe there's a better compromise:
I think this was the intent with #103 but we never followed through and didn't switch on the service. |
I think cookbook template pre-commit is failing:
|
I got that same error locally. It was resolved by updating some package versions in the .pre-commit-config.yaml file in #121. |
For now I've chosen to go with option 4. pre-commit.ci is now running on this repo. Some of the cookbook repos have an out-of-date .pre-commit-config.yaml that should be updated. Turning pre-commit.ci on for those repos would mean that auto-update PRs get generated, but may also cause confusion. We can come back to this later! |
We discussed some pros and cons of running pre-commit on cookbook repos at today's IWG. The main pro argument is for ease of maintenance. Sticking to a consistent code style should lower the barrier for other folks aside from the original author to help with maintenance of notebooks in cookbooks. The main con is the additional complexity and consequent need to write more guidance for cookbook authors. For now we are taking no action but leaving the above compromise (option 4) in place. |
I'm confused about the current state of our reliance on pre-commit for code quality.
In Foundations we have pre-commit.ci running on every PR. This service runs as a GitHub App linked to the Foundations repo.
I don't think we've ever turned this on for any Cookbook repos.
However as of #103 the Template repo has a .pre-commit-config.yaml, and pre-commit was run locally once on the repo.
All subsequent copies of the Template have the .pre-commit-config.yaml file included, but we're using it for anything.
It would be great to get this cleaned up for consistency. I see three options:
Option 3 results in the strictest adherence to consistent code quality and formatting, with some potential for user confusion.
Option 1 is the easiest.
Option 2 is a wishy-washy bad compromise in my opinion.
@ProjectPythia/infrastructure thoughts?
The text was updated successfully, but these errors were encountered: