Issue with import ordering per pyproject.toml

[ethagnawl]

First of all, thank you so much for putting this project together. I was banging my head against my desk for hours trying to get Syntastic (I know ...) and Autoformat working with Ruff and your project worked on the first try. It'll take a day or two to get used to the new commands but I can't be bothered to revisit the janky things I was doing to shim Ruff into my crusty old workflow. (I swear I could have written your Motivation section myself. 😝)

Anyways! While the basics are working as expected, I'm now trying to use this plugin in a project and am seeing a potential issue with the rules defined in pyproject.toml. I have verified that both running ruff check --select I app/some/file.py and our CI job are sorting imports correctly according to the config but my usage of this plugin is not. This could very well be an issue on my end, as this is all new to me.

I have verified that the plugin is loading pyproject.toml as expected. After adding a print statement, I see the following when running :Ruff:

{'tool': {'black': {'line-length': 88, 'exclude': '/(\n  | migrations\n  | .venv\n  | .git\n)/\n'}, 'ruff': {'select': ['I', 'F401', 'E4', 'E7', 'E9', 'F'], 'line-length': 88, 'exclude': ['management', 'migrations
', '.git', '.venv', '_scratch.py'], 'isort': {'force-single-line': False, 'combine-as-imports': True, 'case-sensitive': True, 'lines-after-imports': -1, 'lines-between-types': 1, 'order-by-type': False, 'from-firs
t': False, 'section-order': ['future', 'standard-library', 'django', 'strawberry', 'third-party', 'first-party', 'local-folder'], 'known-first-party': ['tenant_app', 'tenant_models', 'public_models'], 'known-third
-party': ['loguru'], 'default-section': 'third-party', 'force-wrap-aliases': True, 'sections': {'django': ['django'], 'strawberry': ['strawberry', 'strawberry_django']}}}}}

The result displayed on the left in this screenshot is what gets produced by this plugin and on the right is what is produced by invoking ruff on the CLI. (This screenshot is our CI job "fixing" my ordering.)

This is the relevant bit of my .vimrc

let g:vimruff_default = "both"
let g:vimruff_check_select = "I"

Interestingly, I've verified that if I hardcode the path to both my pyproject.toml and the file I'm trying to check into ruff_check then it does detect the "error" but it dumps that output into my Vim buffer. (This may be related to your comment 'ruff check --fix -' on error returns the whole input via stdout)

So, am I doing anything obviously wrong in my use of this plugin? Is there any additional information I can provide? Thanks!

[shaoran]

Hi,

nice to read that you've found my project useful. Sorry, in the last couple of weeks I've been really busy, did not have time to really check your issue. I'll try to take a look at it in the next couple of days.

[shaoran]

Which python version are you using? The plugin tries to use tomllib which has been added in the standard python library in 3.11. If it cannot be imported, the plugin tries to import [tomli](https://pypi.org/project/tomli) which has the same API as tomllib. Can you check which one is being used? It may be, that tomli returns a slightly different dictionary?

I have verified that the plugin is loading pyproject.toml as expected. After adding a print statement, I see the following when running :Ruff:

can you use pprint.pprint(...., sort_dicts=False)? I know the output will be more verbose, but more readable. I don't see a vimruff section in your pyproject.toml, everything from this file will be ignored. So that doesn't seem to be the source of the problem.

Can you please execute in your vim :Ruff info? What do you get?

If you see a difference between :Ruff and ruff on the command line, then we need to inspect the command line.

In autoload/vimruff.vim on line 171, there is the function def exec_command(command: str, content: str). Can you add

pprint.pprint(shlex.split(command))

and then execute :Ruff. This will give you the actual commands that the plugin is executing.

[ethagnawl]

Thanks very much for following up, @shaoran! I will try to do the above and follow up early this week.