Adopt ruff and use less pre-commit

[blink1073]

Adopt ruff, "an extremely fast Python linter, written in Rust."

It is still listed as alpha, pending a couple of open issues, but it is already used by several major projects including hatch.

Copies the pattern used by hatch for linting, formatting, and typing.

[blink1073]

cc @ofek

[codecov]

Codecov Report

Base: 80.01% // Head: 79.97% // Decreases project coverage by -0.04% ⚠️

Coverage data is based on head (4d2a71b) compared to base (7b8008e).
Patch coverage: 78.28% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1114      +/-   ##
==========================================
- Coverage   80.01%   79.97%   -0.05%     
==========================================
  Files          68       68              
  Lines        8013     8023      +10     
  Branches     1586     1587       +1     
==========================================
+ Hits         6412     6416       +4     
- Misses       1179     1185       +6     
  Partials      422      422              

Impacted Files	Coverage Δ
jupyter_server/auth/__main__.py	0.00% <0.00%> (ø)
jupyter_server/auth/security.py	75.67% <0.00%> (ø)
jupyter_server/extension/utils.py	84.21% <0.00%> (ø)
jupyter_server/services/kernels/handlers.py	88.73% <0.00%> (ø)
jupyter_server/services/sessions/handlers.py	80.16% <0.00%> (ø)
jupyter_server/terminal/api_handlers.py	0.00% <0.00%> (ø)
jupyter_server/services/api/handlers.py	93.22% <33.33%> (ø)
jupyter_server/base/handlers.py	78.82% <50.00%> (+0.04%)	⬆️
jupyter_server/extension/application.py	73.36% <50.00%> (+0.23%)	⬆️
jupyter_server/traittypes.py	65.54% <50.00%> (ø)
... and 25 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ofek]

Ruff catches so much 🙂

[blink1073]

Hmm, wow, our mypy tests were not running at all it seems. We legitimately have 160+ errors running mypy --install-types --non-interactive on main, but no errors when running pre-commit run --all-files --hook-stage manual mypy.

[ofek]

I dislike pre-commit

[blink1073]

I dislike pre-commit

I'm coming to the same conclusion

[blink1073]

Okay, this is as far as I can remove pre-commit itself without modifying the hook that is created in hatch-jupyter-builder. I'll create a new option in hatch-jupyter-builder that makes a pre-commit hook on an editable install that runs a hatch command against the modified files.

[blink1073]

cf jupyterlab/hatch-jupyter-builder#97

[kevin-bates]

@blink1073 @ofek - I'm curious about the "dislike pre-commit" comments and merely trying to better understand. Could you please elaborate on some of the pain points?

[ofek]

• Extra layer of overhead/obfuscation
• Doesn't use PyPI by default but instead builds each project repo

Quotes of others in Discord that I agree with:

---

Every time I encounter pre-commit I just pip install the packages from pre-commit and run the commands manually

---

I personally very much dislike pre-commit, and I think it's existence in a repo is a footgun for new contributors

pre-commit wants you to install it as a pre-commit hook, which makes actually contributing to the repository awful (git commit becomes super slow, randomly doesn't work if you have a linting problem, etc).

Everyone I know who works on a project that uses pre-commit says "oh I never install the hooks, that would be awful, I just manually run it".

Except that requires knowing that you can do that. If you follow the setup instructions on the pre-commit page, they treat installing the hooks as a mandatory step, and manually running command as some optional thing. Which means that someone who isn't familiar with the tool, just following along the setup instructions is almost practically guaranteed a frustrating experience.
I'm very much not a fan of tools where the "golden path" has problems like that, and seemingly nobody actually uses it that way. It just ends up being a trap that ensnares unsuspecting people

---

Actually the first time I ever encountered pre-commit I just quickly ran through the setup instructions and didn't pay attention to what it was doing, so I didn't notice it was installing git hooks, as soon as I noticed that the project I was trying to contribute to's dev setup broke my git commit using that, I got mad enough I just deleted all my local work and moved on instead of contributing the fix I had for a bug

[blink1073]

Thanks @ofek! This is making me think that any sort of pre-commit hook should be opt-in, which is how it used to be in the original notebook repo. We provide a one-liner in our contributing guides on how to set it up, and then make it so the JupyterLab probot automatically lints in the same way that pre-commit ci is doing for us now.

[blink1073]

After thinking about it more, I think we do want to preserve some aspects of pre-commit, as it does give us some conveniences. I'd rather not add things to the bot if pre-commit CI is already doing it.

I left the builtins, black, ruff --fix,mdformat and check-jsonschema. There are no more manual stage hooks.

[jesshart]

• Extra layer of overhead/obfuscation

• Doesn't use PyPI by default but instead builds each project repo

Quotes of others in Discord that I agree with:

---

Every time I encounter pre-commit I just pip install the packages from pre-commit and run the commands manually

---

I personally very much dislike pre-commit, and I think it's existence in a repo is a footgun for new contributors

pre-commit wants you to install it as a pre-commit hook, which makes actually contributing to the repository awful (git commit becomes super slow, randomly doesn't work if you have a linting problem, etc).

Everyone I know who works on a project that uses pre-commit says "oh I never install the hooks, that would be awful, I just manually run it".

Except that requires knowing that you can do that. If you follow the setup instructions on the pre-commit page, they treat installing the hooks as a mandatory step, and manually running command as some optional thing. Which means that someone who isn't familiar with the tool, just following along the setup instructions is almost practically guaranteed a frustrating experience.

I'm very much not a fan of tools where the "golden path" has problems like that, and seemingly nobody actually uses it that way. It just ends up being a trap that ensnares unsuspecting people

---

Actually the first time I ever encountered pre-commit I just quickly ran through the setup instructions and didn't pay attention to what it was doing, so I didn't notice it was installing git hooks, as soon as I noticed that the project I was trying to contribute to's dev setup broke my git commit using that, I got mad enough I just deleted all my local work and moved on instead of contributing the fix I had for a bug

As a lurker on this thread, I'm curious about the application of "not liking pre-commit."

What is the recommended way for:

• standardizing linting etc. for developers sharing repo work
• having automation tools run the same linting etc. as mentioned above