Skip to content
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

Support for docformatter rules #1335

Closed
cpcloud opened this issue Dec 22, 2022 · 11 comments
Closed

Support for docformatter rules #1335

cpcloud opened this issue Dec 22, 2022 · 11 comments
Labels
question Asking for support or clarification

Comments

@cpcloud
Copy link

cpcloud commented Dec 22, 2022

We just moved our linting setup over to ruff and it's great!

It would be amazing if we could remove our docformatter dependency as well in favor of ruff.

@cpcloud
Copy link
Author

cpcloud commented Dec 22, 2022

It's possible we can use the ruff pydocstyle support for this too, which may obviate the need for docformatter support.

@charliermarsh
Copy link
Member

Awesome :)

Yeah I've used docformatter in the past, it's great! I wonder how much of its functionality is covered by our pydocstyle support with autofix enabled. I'd need to do a full audit... But I'd definitely like Ruff to be a full replacement for docformatter in that sense.

@charliermarsh charliermarsh added enhancement question Asking for support or clarification labels Dec 22, 2022
@charliermarsh
Copy link
Member

(Labeling as question, to figure out what Ruff is missing here, but it's not necessarily aimed at you.)

@cpcloud
Copy link
Author

cpcloud commented Dec 22, 2022

In the meantime, I've flipped on the D switch and it appears to cover what we're currently using docformatter for, which was effectively a less-strict pydocstyle with the ability to actually fix things instead of only reporting them.

Since ruff covers both linting and fixing I think at least for ibis we no longer need docformatter support.

@charliermarsh
Copy link
Member

Okay cool! (Note that some of the D rules are conflicting, like "No blank line before class" vs. "One blank line before class", since we support a couple different docstring conventions: https://github.com/charliermarsh/ruff#does-ruff-support-numpy--or-google-style-docstrings)

@cpcloud
Copy link
Author

cpcloud commented Dec 22, 2022

Yeah, the list of ignores I'm using for that category of lints is ... long.

@charliermarsh
Copy link
Member

It might be easier to explicitly enable via --select if you want? I can post the list here if you post your ignores (and I could add it to the docs).

@cpcloud
Copy link
Author

cpcloud commented Dec 22, 2022

It's actually not too bad:

ignore = [
  "E501",
  "PGH003",
  "RET504",
  "RET505",
  "RET506",
  "RET507",
  "RET508",
  "D100", # public module
  "D101", # public class
  "D102", # public method
  "D103", # public function
  "D105", # magic methods
  "D107", # init
  "D202", # blank lines after function docstring
  "D203", # blank line before class docstring
  "D205", # blank line between summary line and description
  "D213", # Multi-line docstring summary should start at the second line
  "D402", # First line should not be the function's signature
  "D417", # Missing argument descriptions
]

@cpcloud
Copy link
Author

cpcloud commented Dec 22, 2022

And then of course this bit:

[tool.ruff.per-file-ignores]
"*test*.py" = ["D"] # ignore all docstring lints in tests

@charliermarsh
Copy link
Member

Ah okay yeah, in that case it's more concise to specify the ignores than the selects, which would be like:

select = [
  "D104",
  "D106",
  "D200",
  "D201",
  "D204",
  "D206",
  "D207",
  "D208",
  "D209",
  "D210",
  "D211",
  "D212",
  "D214",
  "D215",
  "D300",
  "D301",
  "D400",
  "D403",
  "D404",
  "D405",
  "D406",
  "D407",
  "D408",
  "D409",
  "D410",
  "D411",
  "D412",
  "D413",
  "D414",
  "D415",
  "D416",
  "D418",
  "D419",
]

@charliermarsh
Copy link
Member

Closing for now since I think we actually have good coverage here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Asking for support or clarification
Projects
None yet
Development

No branches or pull requests

2 participants