Giters

sublimelsp / LSP-pyright

Python support for Sublime's LSP plugin provided through microsoft/pyright.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Default to simple path/name search if can't find anything?

oerp-odoo opened this issue · comments

commented

Im used to SublimeCodeIntel that would simply look for same class names/methods in specified paths. This way I could quickly access imported modules/classes etc.

With pyright, I understand that it tries to do more sophisticated things, but at the same time, when it fails, it won't find anything, which is quite useless. Maybe there is a way to fallback to some simpler imports detection if pyright cant figure out where that import is coming from?

For example I use odoo and include odoo in my project, yet it can't detect most imports properly.

This is my current project config json:

{
  "include": [
    "src",
    "scripts",
  ],
  "ignore": [
    "entrypoint"
  ],
}

This is one of odoo files I opened:

Selection_190

For example if I hover over api, it shows error: "api" is unknown import symbol Pyright: reportGeneralTypeIssues. Clicking on that just redirects to pyright configuration documentation github page..

Here is a link to odoo source, to if you need to see how various modules are imported etc: https://github.com/odoo/odoo/
Here is file I tested locally: https://github.com/odoo/odoo/blob/15.0/addons/account/models/account_account.py

I guess pyright would not be able to properly recognize inherited classes, etc? Because odoo inherits indirectly, somewhat similarly as django, like:

class AccountAccount(models.Model):
    _name = "account.account"
    _inherit = ['mail.thread']

Where you only specify base Model, but business model is inherited via _inherit attribute. As I see it can't see any super implementations of some methods.

P.S. odoo project for me locally is acting like a separate directory, which later is just copied to docker image to be built.

commented

when lsp looks up failed, it fallback to ST's lookup afaik.

commented

how is your project directory structure? and ideally, a minimal repo for reproduction would be nice given the fact that not every one is familiar with odoo and willing to learn it just for this issue.

commented

Are we talking about "Go to definition" (F12)? I don't think we fall back to native "go to definition" in that case.

commented

Are we talking about "Go to definition" (F12)? I don't think we fall back to native "go to definition" in that case.

Not sure why I have that in mind that I saw it in the official docs a long time ago 🤔

commented

https://github.com/trinhanhngoc/odoo-stubs

someone makes this so i guess stubs may be necessary.

maybe you can try to put the odoo-stubs directory as typings/oodo/ under your project root and restart st.

commented

I digged a bit more. It seems now even ST can't find some paths. Though it used to find it no problem when I used ST3. Today I upgraded to ST4 and some paths can't be found by both pyright and ST4.

But other paths can be found by ST4, but not pyright. And the problem seems that pyright blocks fallback or something, because its pop-up is showed instead of default one. Which means, I can't see ST4 suggestions.

If I disable pyright (also have to reopen file for ST4 to start suggesting again) and hover over models.Model, I see this:

Selection_191

So it simply searches for same named definitions.

But if I enable pyright, I get pyright pop up (can't make screenshot, because for some reason it automatically hides when doing printscreen..).

There is something like:

Model: Unknown
Definition | Declaration | References | Rename

And none of these work. I click and nothing happens. Only Rename opens up new pop up, which also does not seem to work (already reported).

So how that fallback should work then?

commented

https://github.com/trinhanhngoc/odoo-stubs

someone makes this so i guess stubs may be necessary.

maybe you can try to put the odoo-stubs directory as typings/oodo/ under your project root and restart st.

Don't I need to include it in configuration or it should pick up such path automatically?

commented

@oerp-odoo typings is the default stubs direcotry for pyright.

commented

I updated my config like (downloaded those stubs and have put it into home/oerp/src/odoo-stubs dir.:

{
    "include": [
    "src",
    "scripts"
    ],
    "ignore": [
    "entrypoint"
    ],
    "stubPath": "/home/oerp/src/odoo-stubs/odoo-stubs",
    "pythonPlatform": "Linux",
    "executionEnvironments": [
        {
            "root": "code"
        }
    ],
    "typeCheckingMode": "basic",
    "pythonVersion": "3.9"
}

But still getting these errors:

/home/oerp/src/docker-odoo/src/odoo/addons/account/models/account_account.py:
    2:18  error   "api" is unknown import symbol ​Pyright:
    2:23  error   "fields" is unknown import symbol ​Pyright:
    2:31  error   "models" is unknown import symbol ​Pyright:
    2:39  error   "_" is unknown import symbol ​Pyright:
    2:42  error   "tools" is unknown import symbol ​Pyright:
  384:53  error   Operator "+" not supported for types "list[tuple[Literal[1], Unknown, dict[str, Unknown]]]" and "list[tuple[Literal[2], Unknown]]" ​Pyright:
                    Operator "+" not supported for types "list[tuple[Literal[1], Unknown, dict[str, Unknown]]]" and "list[tuple[Literal[2], Unknown]]"
  644:22  error   Operator "+" not supported for types "list[str]" and "list[tuple[Literal['code_prefix_start'], Literal['=ilike'], Unknown] | tuple[Literal['name'], Unknown, Unknown]]" ​Pyright:
                    Operator "+" not supported for types "list[str]" and "list[tuple[Literal['code_prefix_start'], Literal['=ilike'], Unknown] | tuple[Literal['name'], Unknown, Unknown]]"
commented

Hm, I added stubs in /home/oerp/src/docker-odoo/typings/odoo, which is in root directory of project (same dir pyright config is located). Now it opens api, models etc, but it actually opens stubs, not real files..

commented

OK, gonna check this tomorrow. Though tried your way too, same thing. It opens stub files instead of real ones..

EDIT: Yeah it seems this is already reported issue: https://githubmemory.com/repo/sublimelsp/LSP-pyright/issues/90

Is there a way to then disable pyright pop up in such case and show default ST one? Cause pyright prevents any of standard pop up to be showed at all, which breaks fallback functionality.

commented

may also try

    "include": [
    "src/*",
    "scripts"
    ],

or

    "include": [
    "src/odoo",
    "scripts"
    ],

according to your screenshot in #96 (comment)

commented

I tried src/odoo, but does not seem to change anything. Regarding original pop up, now when hovering over some module etc, I press F12, which triggers ST behavior. So using as workaround. Yet its a bit clunky, because it automatically opens first found reference even if thats not the one you wanted. After that you get original pop up, where you can see all references.

And regarding my mentioned issue at https://githubmemory.com/repo/sublimelsp/LSP-pyright/issues/90

Is this expected? There it is talked about definitions that might not exist (or be not reachable properly) like builtin pop etc. But in my case code exists, yet it still opens stubs instead of actual code.

commented

And regarding my mentioned issue at githubmemory.com/repo//issues/90

That's different from your issue. What he asked is for source codes which are not written in python, so there are stubs for help. There is no way to navigate to native codes. While in your issue, odoo is written in python so with proper setup, it may be resolve-able.

If you don't mind to provide a ready-for-reproduction repo, that may be save our time. I am not saying it will be resolved but it will be much faster to test for people who may want to help.

commented

OK, I will create sample repo with odoo included. Basically all its needed, is odoo, pyright config and maybe those odoo-stubs

commented

Here is sample repo that I was able to reproduce same issue (opening stubs instead of real code): https://github.com/oerp-odoo/sample-for-pyright

commented

I change the config from you repo by replace "include" with "extraPaths" and it seems to work on my side (both stubs for analysis and go to def to py module)

{
    "extraPaths": [
        "src/odoo",
    ],
    "pythonPlatform": "Linux",
    "executionEnvironments": [
        {
            "root": "code"
        }
    ],
    "typeCheckingMode": "off",
    "pythonVersion": "3.9"
}

extraPaths [array of strings, optional]: Additional search paths that will be used when searching for modules imported by files.

https://github.com/microsoft/pyright/blob/1.1.186/docs/configuration.md

But I feel it's a bit of weird to do this, maybe there is a better config option for this case (when developing a lib it self?).

commented

Thanks, it works on my end too if I change include to extraPaths. Yes its a bit confusing from config side, that it explicitly needs extraPaths, but that will do I guess:)

commented

Seems to be resolved.