-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
update autoflake min version to 2.1.0 #94
Conversation
|
77b1970
to
a4e1a41
Compare
For some reason it is now multiline :-( |
If we look at the file, it's multiline before formatting so I think this is actually a good thing - this change means we're respecting the magic trailing comma when removing unused imports. So if you run locally and commit that diff we'll be ready to merge! |
This is super funky - first pass it's multiline, 2nd pass it's one line |
So what result do we want? May be we need a passing the source code in shed twice for it to work? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, if only the tests were passing!
I think we need to work out whether it's isort
or autoflake
(or potentially another tool) causing this instability, and then report upstream that it's not idempotent. Hopefully they can then fix that, and we'll then depend on the fixed release...
It's isort that is being naughty (changing the multiline to a single line). I will have a look upstream then |
To think of it, what we really want is isort to respect the already multiple-line import to remain multiple line, right? In this test case, autoflake (or other tools) remove the un-used import and now it become "too short" for multiple-line (according to sort). I think it makes sense from the perspective of each single tool (and it accidentally cause us problem as we are using them consecutively) I don't see there is something very wrong with isort, except the fact that if you are only importing a few things it will put it in one line (and sort it) for you. I am not sure if it is a strong enough case to open an issue and PR upstream. We can of cause fix it on our end about the idempotent by running it twice. I need your opinion on that @Zac-HD |
I think non-idempotence is a bug in isort, so constructing a minimal failing example which demonstrates that and reporting it upstream would be good. Until that's fixed, I don't think we can actually get a performance benefit here 😢 |
I have opened an issue at isort, I will have a look there to see if I can provide a PR. This one will have to wait I guess |
…e blocks in docstrings, not all strings
(setting next to @Cheukting now at EuroSciPy sprints :D) |
This is what it looks like after using the setting @alessiamarcolini recommended. @Zac-HD do we want to use it to by pass the upstream issues? |
If we can get this to work in Shed without needing upstream changes, that would be great! |
Handled in #105 🙂 |
closes #88