isort icon indicating copy to clipboard operation
isort copied to clipboard

Make src_paths behave as expected when using --resolve-all-configs and improve performance

Open sudowork opened this issue 2 years ago • 2 comments

When using --resolve-all-configs, there is unexpected behavior in that src_paths ends up resolving relative to the project root, which defaults to the current working directory. This results in first-party modules being marked as third-party modules in the default case.

Under the previous implementation, one possible workaround would be to specify the relative path to config directory (e.g. relative/path/to/configdir/src). However, assuming that the most common use of --resolve-all-configs is to support multiple sub-projects in the same repository/overall directory, this workaround would now require each sub-project to understand where it lives in the filesystem.

This change proposes a fix that sets directory on the config_data to be the directory containing the used configuration file if not already set. Downstream, this directory is then used to resolve the absolute paths specified by src_paths.

This change also introduces performance improvements to find_all_configs by pruning as we walk the filesystem and other smaller performance enhancements.

Fixes #2045

sudowork avatar Jun 06 '23 23:06 sudowork

One thing of note: This would be backwards incompatible for anyone depending on the behavior of resolving first-party src_paths from the project root or config root. However, my assumption is that the behavior this change introduces is what users would expect given the types of config files we look for (.isort.cfg, pyproject.toml, setup.cfg, tox.ini, .editorconfig). The only odd one out in my opinion would be .editorconfig, which supports having a non-root configuration; however, given the behavior of the --resolve-all-configs flag to only choose the closest config file, I opted to not handle this case for consistency and to avoid further complicating the code.

This change also makes the behavior consistent with configuring a settings path.

sudowork avatar Jun 06 '23 23:06 sudowork