Improve line-length vs. autofix interactions (force-allow? force-disallows?)

[tdulcet]

Please consider adding some method to force all autofixes regardless if they might make some lines too long. When using an autoformater (e.g. Ruff), any excessively long lines would be fixed anyway. Maybe do this automatically when E501 (line-too-long) is not selected. This would save a considerable amount of time when switching a large project to Ruff, as it would eliminate the need for unnecessary manual fixes.

This potential workaround does not work:

$ ruff --line-length 9999 --unsafe-fixes --fix .
error: invalid value '9999' for '--line-length <LINE_LENGTH>': The line width must be a value between 1 and 320.

Some fixes need more than 320 columns, so using --line-length 320 would not work either.

$ ruff --version
ruff 0.1.1

[charliermarsh]

I'm wondering if we should just remove this behavior, or mark those fixes as unsafe when they would exceed the line length. I'd sort of rather do one of those two things instead of introducing a setting or similar. \cc @zanieb

[zanieb]

Could we format the fix with our formatter i.e. using range formatting?

I think changing from safe to unsafe due to a line length violation is kind of a misuse of applicability.

It'd probably make sense to just apply the fixes despite the line length; is there a good example I could see that demonstrates the problem with that?

[Avasam]

My opinion: fixing one reported lint issue can introduce another (sometimes multiple layers of code smells/code simplification can happen). To me that's to be expected.

I see line length the same way. Especially since line length is often an easy manual fix. (and automated with a formatter).

Line length also doesn't break code. It feels unexpected for a safe autofix to not happen.

[tdulcet]

Yes, I agree, I think it is surprising for many Ruff users that they are not seeing all possible autofixes by default, especially now that Ruff supports autoformating. This is different from every other linter I have used that supports autofixes, including ESLint, Clang-Tidy and Shellcheck. I only noticed this recently after I increased the --line-length option and saw that a bunch of new possible autofixes were listed. I then increasing it again and there were more autofixes still... 🤯

It'd probably make sense to just apply the fixes despite the line length; is there a good example I could see that demonstrates the problem with that?

This sounds like the best solution. I believe there are some cases with f-strings where it is not currently possible to format them with Ruff to reduce the line length, but it is my understanding that this will be fixed after Ruff fully supports the preview style formatting, so this should be a nonissue.

(There are several autofixes that flatten code originally written over multiple lines and in some cases can cause very long lines. If these autofixes could instead preserve the existing formatting and only make minimal changes, this would be a big improvement and would also make it easier to see the actual proposed change with the --diff option, but this still would not handle all cases where long lines are unavoidable without some type of autoformating.)

[MichaReiser]

I'm wondering if we should just remove this behavior, or mark those fixes as unsafe when they would exceed the line length. I'd sort of rather do one of those two things instead of introducing a setting or similar.

I'm leaning towards just removing the behavior without marking them as unsafe, because the fixes are not unsafe in the sense that they change the program's semantic. There's only the risk that they introduce new errors.

[charliermarsh]

I'm definitely open to removing it, but I should at least mention that it didn't appear out of nowhere. We introduced that logic because we received multiple issues complaining about the fact that these fixes introduced E501 errors. I found this one, as an example: #1766.

Could we format the fix with our formatter i.e. using range formatting?

I think this is the ideal (and desired) solution but it's not a trivial change.

[MichaReiser]

Could we format the fix with our formatter i.e. using range formatting?

Maybe, but even when we use our formatter, there's still no guarantee that it won't trigger E501.

[tdulcet]

We introduced that logic because we received multiple issues complaining about the fact that these fixes introduced E501 errors.

As I suggested above in my original request, maybe only remove this behavior when the user does not have E501 selected. Now that E501 is no longer selected by default, this would likely fix the issue for the majority of users without causing any additional errors for those who have chosen to explicitly enable E501. If you chose this path, it might also be helpful to warn about any hidden autofixes due to E501 so that users would be aware of the issue, similar to how Ruff now warns about hidden unsafe autofixes.

[zanieb]

Maybe, but even when we use our formatter, there's still no guarantee that it won't trigger E501

It seems like it'd be a good enough effort though. Additionally, we could check the line length after formatting as a determination of whether or not the fix should be suggested although I think this is a bit much.

As I suggested above in my original request, maybe only remove this behavior when the user does not have E501 selected.

This sounds like a bit of a confusing experience to explain and is not a pattern I'd want to embrace in general. line_length is a global Ruff setting, not just E501.

If you chose this path, it might also be helpful to warn about any hidden autofixes due to E501 so that users would be aware of the issue, similar to how Ruff now warns about hidden unsafe autofixes.

It makes me uncomfortable to special case messaging for the line length rule like this. I don't think this is actually possible with our current fix architecture either.

I think the example in #1766 is quite helpful. A formatter would not resolve that and it is a significant degradation in readability.

[charliermarsh]

@zanieb - I wonder if there's... some other way for us to gate that simplicity rule, in those cases. Like, if the body is multiline, perhaps we should skip that rule, since it's unlikely to be "simpler"?

[Avasam]

Since the message No fixes available (X hidden fix can be enabled with the '--unsafe-fixes' option). exists. Could the same be added for line length? Like No fixes available (X fix skipped due to line-length). (doesn't really solve cases above 320, but at least the user is made aware, and not left to think Ruff is inconsistent)