`--sort-reexports` does not respect `--profile=black`

[Helveg]

Problem

Attempting to sort a multiline __all__ attribute that is longer than the line limit with isort . --sort-reexports --profile=black wraps the lines in a non-black compatible way:

Before

__all__ = [
    "ArgumentReference",
    "ConfigurationSource",
    "HeptoFlow",
    "HeptoFlowContainer",
    "InMemoryCache",
    "Input",
    "InputReference",
    "InputValue",
    "Service",
    "parse_input_expression",
]

After

__all__ = ['ArgumentReference', 'ConfigurationSource', 'HeptoFlow', 'HeptoFlowContainer',
 'InMemoryCache', 'Input', 'InputReference', 'InputValue', 'Service',
 'parse_input_expression']

Env

Python 3.12
isort 5.13.2
black 24.4.2

PS: Very willing to fix this myself and to PR it if someone can triage this and point me in the right direction.

[Helveg]

I did some digging and it seems that code sorting (sort_reexports and the undocumented and quasi-untested sort comments # isort: list, # isort: unique-list, etc) is the only feature that uses isort.literal.assigments. This function relies on the Python stdlib pprint formatting, and completely ignores the config, except for line_length:

class ISortPrettyPrinter(PrettyPrinter):
    """an isort customized pretty printer for sorted literals"""

    def __init__(self, config: Config):
        super().__init__(width=config.line_length, compact=True)

There is no regard for the config.multi_line_output, config.include_trailing_comma, config.split_on_trailing_comma, and likely many more that I am not aware of as a first-time contributor.

I believe fixing this would require us to write our own formatting logic, since pprint does not support any of the configurable formatting features isort needs.

I would need the input of the developers here, since there are no tests to form a de facto specification, but I believe that code sorting should follow the Config formatting options, and the pprint logic should be dropped and an isort algorithm like the ones in isort.output should be used or custom written for it.

[Helveg]

@timothycrosley Hi, sorry for the direct ping, I'm sure you're very busy! Would you have a moment to confirm my suspicions that the code_sorting logic is insufficient, and preapprove my attempts to rewrite it? If I have your green light I can get started on it.

I already have a PR open for fixing similar sort_reexport problems that would require your attention: https://github.com/PyCQA/isort/pull/2283

Hope to hear from you, and have a good day

[lord-haffi]

Hi @Helveg, just kindly asking, is there any update on this issue?

[Helveg]

Yes, this was merged and released in version 6. Can you let me know if it works as expected in v6 for you? If so, I'll close the issue

[lord-haffi]

Unfortunately not. I used isort 6.0.1 but this exact issue still persists. Does it work for you? Maybe I'm doing something wrong.. I think you mean #2283, right? But as far as I saw, it doesn't encounter this issue, does it?

[staticdev]

@Helveg Timothy is currently not maintaining isort, but feel free to propose a fix in case you feel like, me and other contributors are applying latest changes.

[Helveg]

Oh ok, sorry @lord-haffi I must've gotten my wires crossed :) If I have a quiet weekend I can take a look at this

[lord-haffi]

No worries bud, I was just curious :P Take your time :) I'd do it myself but when I took a look at the codebase... Well, let's say, it'd cost me more than a quiet weekend to work on it ^^

[lord-haffi]

Hi, is there any update on this? Just tried it again with isort version 7 and the issue remains. If you can guide me, where I have to look, I could also try it myself.