Isort: Different third vs first party behaviour in isort 5 (vs isort 4)

Created on 8 Sep 2020 · 3Comments · Source: PyCQA/isort

Hi,

It seems the behaviour changed for isort 5 related to first party, third party sections.

folder structure

$ tree .
.
├── bar/
└── code.py

`code.py` output for isort 5.5.1:

cmd $ isort code.py

import json

import foo

import bar

Notice the extra line between import foo and import bar

`code.py` output with isort 4.3.21:

cmd $ isort code.py

import json

import bar
import foo

Real life case

This this diff linked here represent the code change before (isort 4) and after using isort 5:
https://github.com/DataDog/integrations-core/pull/7540/commits/518d8b71fdbedb2726612d37e3f8d6f7a9b9d7f8

Source

AlexandreYang

👍1

All 3 comments

Hi @AlexandreYang thanks for reporting this issue!

I believe for this exact issue in the datadog repository, you can achieve the behaviour you want simply by telling isort not to automatically try to detect based on src_path. This can be achieved by telling isort to use an empty set of src_paths in your config:

[tool.isort]
force_grid_wrap = 0
include_trailing_comma = true
known_first_party = 'datadog_checks'
src_paths = ''

Ideally, the improvements planned to module placement for 5.6.0 would enable this to mostly work automatically, but even so if you simply want everything under datadog_checks to be considered first_party, I believe the above configuration would be preferred as it would perform better and be more explicit.

Side note: What is the best way to run isort across the repository to be consistent with how it is done in your CI? I would love to add this project to the isort integration test suite (https://github.com/PyCQA/isort/blob/develop/tests/integration/test_projects_using_isort.py#L1) so that the isort project can assure that as we make changes they don't introduce regressions.

Thanks!

~Timothy