Provide a way to "force" include an open document even if it is excluded

[mounirmesselmeni]

I was trying to pass --no-force-exclude to Ruff format but it seems to be ignored.

Output from the extension:

Running Ruff with: /home/app/venv/bin/ruff ['format', '--force-exclude', '--quiet', '--stdin-filename', '/app/core/migrations/0011_populate_something.py']

Use case:
I wanted to be able (while generally ignored migrations files), when adding Django migrations by hand, to be able to format them using Ruff.
That was the case with Black and black extension before switching to Ruff, I believe the black extension was ignoring the ignore list.

[dhruvmanila]

Hey, this is because it's one of the arguments which isn't supported for the format.args field: https://github.com/astral-sh/ruff-lsp/blob/187d7790be0783b9ac41ce025a724cf389bf575c/ruff_lsp/server.py#L199-L213

Are you not seeing any warnings for it?

[charliermarsh]

I think we could allow --no-force-exclude? It would just mean that all files are formatted regardless of whether they're marked for exclusion (so even, e.g., files in the standard library would get formatted, if you opened them up). Is that what you wanted to achieve?

[mounirmesselmeni]

@dhruvmanila No warnings, only info logs.

@charliermarsh correct, on the other hand, if I open a standard library of third party library in VSCode, modify and save it it might still be okay to have it formatted, that is mainly done for debugging purposes and would be anyway reverted afterwards.

[dhruvmanila]

As a user, I would find it annoying to always revert back the change which an extension made. But, I could see us providing an option to do so. (cc @snowsignal something to think on for the config proposal)

[jvacek]

Coming here with this usecase:

I have a ruff config that I'd like to have enforced in CI/CD and with pre-commit, but I'd like to make sure that even files that I've marked as excluded are still within the scope of what the ruff extension in vscode can work with, so I can apply ruff "optionally" on these files.

[dhruvmanila]

@jvacek can you try the new native server by setting ruff.nativeServer: "on" (https://docs.astral.sh/ruff/editors/settings/#nativeserver) ? Does that resolve your use-case?

[jvacek]

Under native server, I don't see the intended behaviour either. It seems that the exclude is still being applied.

[dhruvmanila]

@jvacek Can you provide a way for us to reproduce (Ruff and VS Code settings, directory structure, etc.) ?

[jvacek]

Here you go: https://github.com/jvacek/ruff-test

I wish there was a way for me to still be able to run > Format Document on the non-formatting.py. There should be a way to disable force-exclude=True which seems to be baked into the server

[dhruvmanila]

Thanks for creating a repository, it makes our life easier to help us reproduce any issue!

As you can see, it works with the native server:

Screen.Recording.2024-12-04.at.4.52.49.PM.mov

The force-exclude is only baked into the ruff-lsp server and not the native server. Can you make sure you're using the native server by setting the following:

{
	"ruff.nativeServer": "on"
}

Refer to https://docs.astral.sh/ruff/editors/settings/#nativeserver. The auto value which is the default value won't work because the settings contain ruff.format.args which is unsupported in the native server.

[jvacek]

I think we might have a misunderstanding. You're successfully reproducing my issue in the screen recording above. This behaviour is the same on the native server and the LSP.

I want to have the option to have the server ignore the exclude settings in the config.

I want the file not-formatting.py to format when you run Format document on it.

I can run ruff format not-formatting.py to get the file to change, as there, the default is force-exclude=False. The server's default seems to be force-exclude=True, and there's no way to set it to False.

Same goes for linting/ruff check

[dhruvmanila]

I want the file not-formatting.py to format when you run Format document on it.

Ah damn, you're right. I misunderstood your issue, this is what I get when looking at an issue late evening. Sorry for the churn, I'll look at it tomorrow morning and reply accordingly.

[jvacek]

As a user, I would find it annoying to always revert back the change which an extension made. But, I could see us providing an option to do so. (cc @snowsignal something to think on for the config proposal)

To add to this, I do agree. It would be super confusing. I would absolutely keep the current behaviour as default. Just making it configurable would be nice.