Is enforcing import order consistency beneficial enough to justify the added complexity in tooling usage for contributors?

I like consistent import statements but I have the feeling that this additional linter might add a layer of friction (both to first time contributors and to grumpy old-style core developers who might not embrace the joys of a well configured pre-commit setup ;)

For black the ratio of complexity cost vs gains (consistent code style + not having to explains the rules of PEP8 to users) was more favorable.

Thanks for exploring this, @adrinjalali.

I would also be in favour of sorted imports for the longer term, yet I think it comes with drawbacks.

Should we add it to a vote during the next core-dev meeting?

We can discuss and see what people feel like, and then if we think there might be a consensus, we can call for a vote on the mailing list :)

@adrinjalali could you paste what would be a failure in the CI if someone does not import in the right order?

The CI failure shows a clear list of issues. Example: https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=42219&view=logs&j=32e2e1bb-a28f-5b18-6cfc-3f01273f5609&t=8a54543f-0728-5134-6642-bedd98e03dd0

--- /home/vsts/work/1/s/.github/scripts/label_title_regex.py:before	2022-05-17 09:51:04.962912
+++ /home/vsts/work/1/s/.github/scripts/label_title_regex.py:after	2022-05-17 09:51:42.390988
@@ -1,9 +1,10 @@
 """Labels PRs based on title. Must be run in a github action with the
 pull_request_target event."""
+import json
+import os
+import re
+
 from github import Github
-import os
-import json
-import re

Thanks @adrinjalali. I don't find it more complex than the output of black.

If we error with those tools, it could be cool to print a message showing the command to run to fix the problem (for black and isort).

I would be +1 but let's discuss it in the next developer meeting.

If we error with those tools, it could be cool to print a message showing the command to run to fix the problem (for black and isort).

That indeed should help a lot!

So at the dev meeting we decided that the first step would be to improve the CI message to give specific directions to the contributor to fix linter formatted errors by pointing them to a specific command line or a script in the repo (+ the pip install command to install the correct version of black) and optionally link to some online doc that explains how to setup pre-commit.

Then once this is done, we can upgrade this PR to also include isort in the feedback from the CI.

Then, as a nice to have follow-up PR, we could have a bot that provides the CI feedback as a pull request feedback instead of just text hidden in the raw CI log.

superseded by #26649