Feature request: Add Length-Sort config to isort

[einarwar]

Thanks for an awsome library. I am currently trying to replace the old flake8 and isort setup on our repo with ruff.

We can almost replace isort with ruff, but we are currently using the Length-Sort configuration from isort, which currently can't be found in ruff.

[charliermarsh]

Love the Annoy-o-Tron.

[RobertCraigie]

We also need this to be able to migrate to ruff!

[mihirsn]

Hi @charliermarsh 👋🏼 I've started learning Rust for a while but haven't contributed yet and want to start from somewhere. So if you allow can I pick this one ?

[mihirsn]

Hi @charliermarsh, just wanted to know that if you have any idea for the implementation approach for this..if so could let me know I am thinking to pick this up. I saw the comment, a bit confused by it.. so if you can elaborate it would be great.

[vadim-su]

Hi there 👋
I will try to implement this option, but I have a question about the already implemented method.
Do I understand correctly that order_by_type and length-sort are mutually exclusive options? If so, should I add an enum with the options?

[warsaw]

While you're at supporting length-sort, please also support length-sort-straight. That's probably the biggest isort feature I rely on that is missing from ruff.

[warsaw]

Do I understand correctly that order_by_type and length-sort are mutually exclusive options? If so, should I add an enum with the options?

I don't know the answer to that. My guess is that they are not mutually exclusive since different isort options control them, but I don't know how they interact if both are set.

For length-sort and length-sort-straight my guess is that the latter is a subset of the former, but I'm not sure how they interact if say the former were true and the latter were false.

[bluthej]

Hey! I'm currently working on this one and I have a working implementation of the basic functionality. @suharnikov if you're still working on it as well I'll leave it for you of course :)

I do have one question though, I couldn't help but notice that there are a bunch of functions that take in a whole lot of isort settings (like format_imports in rules/isort/mod.rs), and I was wondering why they don't just take in a reference to an isort::settings::Settings? Is there a particular reason for that? I tried changing the function signatures and it seems to work alright that way too.
Having all the settings passed around separately yields a fair amount of tedious work when you're trying to add a new setting because you have to chase down all the places that they need to be added and change all the function signatures.
But if there's a good reason that I just haven't figured out I'd love to know about it 🙂

[charliermarsh]

@bluthej - I think it's probably okay to refactor those methods to accept Settings. If you're able to work on that, do you mind putting it up as a standalone PR, with just that refactor, to make it easier to review and merge?