-
Notifications
You must be signed in to change notification settings - Fork 5
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
Adopt black and ruff #21
Comments
I think this is a great idea in principle! I love black and ruff, and they could be an enormous help in improving code quality. One concern though is that reformatting with I think keeping the diff between forks minimal & understandable is rather important for us, as we want to make it easy to see what has changed in this fork, and we want to be able to merge PRs that were originally raised on the original repo. Arguably that is more important at the moment than having a nice code style. So... should we start with just Ruff but not Black? We should certainly fix the logical issues, e.g. |
I'll chip in here as well. Here are my thoughts:
|
I agree wholeheartedly, @thatlittleboy . On your point (4) about linting new changes to a higher standard, one possibility is given in the ruff docs:
If we went this route, we'd need to distingush somehow between existing |
Thank you for the great feedback @thatlittleboy and @connortann. I agree with your points. I'm definitely in no rush to add comprehensive linting and formatting. I mainly raised this issue so I could cross shap#2594 and shap#2595 off from #2. I like the idea of only applying For now, I'm happy to discuss a minimal set of |
It seems like we've got consensus to avoid Black for now, and to run Ruff on the whole codebase. I think we can close this issue now that #25 has been merged. As a longer-term objective, it would be good to get a greater set of Ruff checks passing. |
Following PRs shap#2594 and shap#2595, consider using
black
andruff
to standardize code style. We may disable manyruff
rules to get started. For example, I don't fancy adding static type checkin to the entire project yet.mypy
would be nice to add one day, and may help with some of SHAP's rough edges.The text was updated successfully, but these errors were encountered: