Consider using pre-commit.ci for style checking in CI

[flferretti]

By using pre-commit.ci, we could eliminate the file related to the style CI configuration, e.g. .github/workflows/style.yml and substitute it with something that leverages the already present .pre-commit-config.yml and the configuration from the pyproject.toml.

This would allow us to add additional checks (see https://github.com/pre-commit/pre-commit-hooks), especially the check-added-large-files, which would prevent the user to commit the pixi.lock pulled from lfs, and the others checks already present in the pre-commit configuration.

[diegoferigo]

Running the pre-commit check also on CI would be great! About the style checks (isort and black), I would just double check about the following:

• We can constrain the version of black as we currently do. In the past, new major releases (once per year, usually around January) introduced breaking changes. I prefer to bump manually the black pinning.
• Right now the CI provides a nicely formatted diff in case there is a style mismatch. Before moving to ruff, let's be sure to get something comparable.

[flferretti]

The formatting packages are already constrained in the .pre-commit-config.yml for both black:

jaxsim/.pre-commit-config.yaml

Line 12 in 5b96fab

rev: 24.2.0

and isort:

jaxsim/.pre-commit-config.yaml

Line 18 in 5b96fab

rev: 5.13.2

Do you prefer to have an error raised with the diff or just let the CI format the commited files?

[diegoferigo]

Nope the pinning looks good. Can we match it with what specified in pyproject.toml? Considering the update policies, I guess that pinning the major versions would suffice.

[flferretti]

The pre-commit configuration needs an exact tag or commit SHA. Can we stick with the current configuration since it matches:

# From pyproject.toml in #193 
"black[jupyter] ~= 24.0"

?

[diegoferigo]

Yes that sounds good, I thought it could handle less strict versioning.