Need help with the linter setup

[S1lander]

Hi there :)

First of all, thanks for maintaining this project, and for merging my little adjustments! The plugin works great 👍🏼 it's fast and very easy to use.

However, I might be missing something about getting the linter set up to work for blender related python files. Right now it's showing a bunch of errors that would make sense in a non-blender related project:

Pulling up the docs and code completion works (I also installed fake-bpy-module):

I'm using the native lspconfig of LazyVim btw. (if that's even relevant). I am still quite new to nvim, so any hints on what to do here would be appreciated!

Thanks in advance

[b0o]

Hey there! Have you created a virtualenv and activated it before starting nvim inside of the same shell? And you say you're using the native lspconfig of LazyVim - have you changed any of the settings? I assume you've added the python extra to LazyVim?

Some of the errors are unavoidable due to how Blender add-ons don't always exactly follow standard Python syntax, like "call expression not allowed in type expression". You will need to configure your lsp/linter to ignore those or use inline ignore directive comments.

For errors/warnings like x is not a known attribute of "None" that often means that if you're trying to do something like foobar.x, the type of foobar might be something like SomeClass | None. To fix this, you should do something like

foobar = get_foobar() # type: SomeClass | None
if foobar is None:
  return
# OR
assert foobar is not None
# the LSP/type checker now knows that foobar can only be SomeClass, so you can safely access its attributes
dostuff(foobar.x)

Another possibility is that the type checker thinks foobar is unknown. In that case, you can use inline ignore directives to ignore the warnings, or if you know what type it really is, you can use type annotations and/or cast it to the desired type.

Finally, a simpler option if you don't want to jump through all of these hoops: if you're using pyright or basedpyright as your LSP (I use basedpyright, personally), you can set it to basic mode, either at the top of the file with a directive like # pyright: basic or set typeCheckingMode in your pyright config. This will silence more advanced typechecking errors but some will still remain.

However, the "Unable to import bpy" implies that you haven't properly installed fake-bpy-module or something is wrong with your LSP/venv. I'd need to know more about your setup to say for certain what's wrong.

[S1lander]

Hey, thanks for your answer!

I've looked a bit more into it since opening the issue and, also with the help of your answer, figured out that I can add some additional rules to the pyproject.toml file like this:

[tool.pyright]
venvPath = "."
venv = ".venv"
extraPaths = [".venv/lib/python3.11/site-packages"]
typeCheckingMode = "basic"
reportMissingImports = false
reportMissingModuleSource = false
reportMissingTypeStubs = false
reportInvalidTypeForm = false
reportGeneralTypeIssues = false
reportAttributeAccessIssue = false
reportUnusedImport = "warning"
reportUnusedVariable = "warning"
reportOptionalMemberAccess = false
reportOptionalSubscript = false
reportPrivateImportUsage = false

And also, I forgot to add this in my lspconfig:

lspconfig.pyright.setup({
	capabilities = capabilities,
})

Using your readme and then adding the stuff above does the job. I'm not completely sure whether it's supposed to be done like that, but it works. Yes I have the env activated before starting up nvim. The only thing now is that it's still reporting "context" as not being accessed. I had the exact same pyright configuration in a separate pyrightconfig.json file before, and it wouldn't show this warning. I might just leave it like this tho, to make sure I can catch other actual problems. Maybe it's not working exactly the same when the config is in the json.

I appreciate your help!

[b0o]

Glad you got it working!

The only thing now is that it's still reporting "context" as not being accessed.

If you mean in cases like this:

def my_method(self, context):
    do_stuff()

You can prefix the argument name with an underscore to silence the warning:

def my_method(self, _context):
    do_stuff()

[S1lander]

Glad you got it working!

The only thing now is that it's still reporting "context" as not being accessed.

If you mean in cases like this:

def my_method(self, context): do_stuff() You can prefix the argument name with an underscore to silence the warning:

def my_method(self, _context): do_stuff()

Yes I mean exactly cases like that, and I've tried the underscore already. For some reason it's still showing the same error, even with the underscore.