Skip to content

Update pre-commit config from trame-cookiecutter#37

Open
Jo-Byr wants to merge 1 commit intoKitware:masterfrom
Jo-Byr:update-pre-commit
Open

Update pre-commit config from trame-cookiecutter#37
Jo-Byr wants to merge 1 commit intoKitware:masterfrom
Jo-Byr:update-pre-commit

Conversation

@Jo-Byr
Copy link
Contributor

@Jo-Byr Jo-Byr commented Jan 30, 2026

There was a conflict between the lint rules in pyproject.toml and the pre-commit config, I had to remove some rules from pyproject.toml, which had for consequence to reduce the max line length from 120 to 80, I don't know if this is something we want to keep.

@Jo-Byr Jo-Byr requested a review from jourdain January 30, 2026 14:13
@jourdain
Copy link
Collaborator

Thanks for taking a stab an making the repo more up to date with the "standard". If some rules don't make sense, you can remove them...

@Jo-Byr Jo-Byr force-pushed the update-pre-commit branch 2 times, most recently from 0ee909a to 8f2d399 Compare February 4, 2026 08:05
@Jo-Byr
Copy link
Contributor Author

Jo-Byr commented Feb 4, 2026

@jourdain why do we have both black and ruff ? I think ruff doesn't only take care of line length, but since they both take care of it, shouldn't we either remove black or ignore E501 in ruff ?

Also black has built-in ignored cases, which ruff does not have (comments for example) and this poses problem here.

@jourdain
Copy link
Collaborator

jourdain commented Feb 4, 2026

Agree, black should not be used now that we are relying in ruff.

I guess that initial list was taken from https://learn.scientific-python.org/development/ and I forgot to remove was a duplicate of mine...

Please feel free to remove black here and in the cookiecutter. Thanks for pointing that out.

@Jo-Byr
Copy link
Contributor Author

Jo-Byr commented Feb 5, 2026

Agree, black should not be used now that we are relying in ruff.

Ruff's formater points out all line-too-long errors, whereas Black "makes a best-effort attempt to adhere to the line-length but avoids automatic line-wrapping in some cases (e.g., within comments)" (ruff documentation). Thus we have multiple E501 errors on :param lines in docstrings and using ruff's formatter would imply either splitting these lines, or adding an ignore comment on every occurence.

But we could also keep black and ruff and ignore E501 errors in ruff's configuration to keep black's behavior on these errors.

@finetjul
Copy link
Member

finetjul commented Feb 5, 2026

I think we have no argument to go against E501. So I suggest we split the lines.

@Jo-Byr
Copy link
Contributor Author

Jo-Byr commented Feb 13, 2026

@finetjul @jourdain It should be all good now.

return `${this.name?.toLowerCase() || ''} ${this.label?.toLowerCase() ||
''}`;
return `${this.name?.toLowerCase() || ''} ${
this.label?.toLowerCase() || ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Jo-Byr did you see those warnings ?

_help: >-
Example of Text widget with numerical entry
With some multi line example...
Example of Text widget with numerical entry With some multi line
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that uppercase is odd here

@jourdain
Copy link
Collaborator

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments