First of all thanks for the plugin, it works very well.
At work we have to import a module at the beggining of the file because we rely on some side effects from the import.
I wanted to force the import to move to the top and it seems the recommended way is to define custom sections together with https://pycqa.github.io/isort/docs/configuration/options.html#known-other.
Since these known_{section} keys are dynamic, they are not present in the dataclass definition for _Config, and are filtered before the isort.Config is created in the plugin.
The proposed change allows any config key that starts with the known_ prefix. I considered generating the list of valid known_ keys from the user-defined sections, but isort already validates that and didn't see the need for duplicating the logic.
First of all thanks for the plugin, it works very well.
At work we have to import a module at the beggining of the file because we rely on some side effects from the import. I wanted to force the import to move to the top and it seems the recommended way is to define custom sections together with https://pycqa.github.io/isort/docs/configuration/options.html#known-other.
So my config would look like:
Since these
known_{section}
keys are dynamic, they are not present in the dataclass definition for_Config
, and are filtered before theisort.Config
is created in the plugin.The proposed change allows any config key that starts with the
known_
prefix. I considered generating the list of validknown_
keys from the user-defined sections, but isort already validates that and didn't see the need for duplicating the logic.An alternative approach would be to add the module to the
FUTURE
section but that is discouraged: https://pycqa.github.io/isort/docs/configuration/options.html#known-future-library