-
Notifications
You must be signed in to change notification settings - Fork 279
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
Style: enforce import ordering with isort (YTEP0037 1/6) #2592
Style: enforce import ordering with isort (YTEP0037 1/6) #2592
Conversation
Actually I was reading through pandas' issue tracker to try and discover how they managed their transition to black on such a large project. Couldn't find the answer yet but doing so I just learned about isort, which seemed like a first step, much more lightweighted rewiew-wise. So yeah, I would also like to see black adopted, but I can certainly understand the anxiety ! In any case I don't want to get in the way of #2437 |
In all fairness if we ran black on the codebase now, and ran it on the PRs,
it should be OK. :)
…On Fri, May 15, 2020 at 2:55 PM Clément Robert ***@***.***> wrote:
Actually I was reading through pandas' issue tracker to try and discover
how they managed their transition to black on such a large project.
Couldn't find the answer yet but doing so I just learned about isort, which
seemed like a first step, much more lightweighted rewiew-wise.
So yeah, I would also like to see black adopted, but I can certainly
understand the anxiety ! In any case I don't want to get in the way of
#2437 <#2437>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2592 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAVXOZZGZZUFMCRGF66NLLRRWM2JANCNFSM4NCQMMGQ>
.
|
Just a quick note: I just tried to combo isort + black on a personal project and they seem to have minor disagreements over formatting of comma-separated multiple-lines imports. |
Here's the pandas thread pandas-dev/pandas#26926 |
e5ee991
to
022d95e
Compare
Apparently doing the isort pass on the whole code base at once breaks the installation (pip install -e . still runs but then the lib is unusable). Going to try a more iterative approach to identify what's going wrong. |
c1d6ba5
to
48b7faf
Compare
After a few iterations and rebasing, I think I've covered every little problem caused by isort-ing the code base. I also made sure to leave it in a state such that (black + isort) would be a commutative combo (only one change was needed for this). There remain 2 open questions:
|
1d8346c
to
8946ed0
Compare
Interestingly, isort gives slightly different results in python 3.6 on travis VS 3.8 on my machine. |
3c7c1c9
to
2621ba1
Compare
32b7cad
to
dc3b237
Compare
928f953
to
bdc33e3
Compare
76abfcd
to
2ac9c58
Compare
Conflicts will show up every time someone changes/adds an import statement in master. I'll wait for this PR to be prioritised to solve this in one clean rebase. |
77cb421
to
f2eb8a3
Compare
quick sanitising of this branch:
actually I'm just going to remove the final commit. That will also facilitate the reviewing process |
f2eb8a3
to
89f1fac
Compare
…d to make the (isort + black) combo commutative
…espaces (np and numpy), which is not handled correctly by isort.
cdae5a4
to
3bbad9d
Compare
PR Summary
isort is a tool that automatically sorts import statements.
It can be configured as a precommit hook too, so it should not be necessary to have this kind of PR, updating the whole code base more than once.
Imo, the 4.0 release would be a nice time to include this kind of nitpicky change, though I can easily imagine how the present PR would clog the yt-4.0 -> master merge, so I wouldn't suggest considering it for a merge ahead of this major task.
CURRENT STATE: This PR should include everything needed to smoothly adopt isort, but doesn't run it on the code base as it used to.
checklist
Validation steps
Documentation and workflow
OPTIONAL: add a precommit hook ?(Done in Add precommit hooks for flake8, isort and black (YTEP0037 5/6) #2600)