Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: allow "useLibraryCodeForTypes" option to be set within config file #928

Closed
fabiencelier opened this issue Aug 10, 2020 · 5 comments
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request

Comments

@fabiencelier
Copy link

Describe the bug

Since pytest version 6 they pretend to have included inline type annotations. I have tried to use them with useLibraryCodeForTypes set to true but pyright still report an reportUnknownParameterType

To Reproduce

pyright version 1.1.61
pytest version 6.0.1

Use this config:

{
    "reportUnknownParameterType": true,
    "analysis": {
        "useLibraryCodeForTypes": true
    }
}

and this test_monkeypatch.py

from _pytest.monkeypatch import MonkeyPatch

def test_something(monkeypatch: MonkeyPatch):
    pass 
> yarn run pyright
yarn run v1.15.2
...
Loading configuration file at [...]/pyrightconfig.json
Assuming Python version 3.8
Assuming Python platform Linux
[...]
Searching for source files
Found 1 source file
[...]/test_monkeypatch.py
  3:20 - error: Type of parameter "monkeypatch" is unknown (reportUnknownParameterType)
1 error, 0 warnings 
Completed in 0.489sec
error Command failed with exit code 1.

Expected behavior
I expect pyright to not report an error as the type looks correct to me.

VS Code extension or command-line
Command line version 1.1.61

Related pytest thread about typing: pytest-dev/pytest#7469

@erictraut
Copy link
Collaborator

Your config is invalid. "python.analysis.useLibraryCodeForTypes" is a VS Code setting, so it needs to go in your VS Code "settings.json" file. Or if you're running the command-line version of Pyright, you need to pass the "--lib" argument to the command-line.

For details about the options that are supported in the config file, refer to this documentation.

For details about options that are supported in VS Code settings, refer to this documentation.

For details about options that you can pass to the command line, refer to this documentation.

@erictraut erictraut added the as designed Not a bug, working as intended label Aug 10, 2020
@fabiencelier
Copy link
Author

Maybe I just can't find it but I don't see an equivalent setting I can put in the config file that would work for both VS code and the command line. Is this by design ?

@erictraut
Copy link
Collaborator

There is no equivalent setting for the config file. You'd need to use a combination of the "python.analysis.useLibraryCodeForTypes" VS Code setting and the "--lib" switch.

I think there's a good argument to add an option in the config file as well.

@erictraut erictraut added enhancement request New feature or request and removed as designed Not a bug, working as intended labels Aug 10, 2020
@fabiencelier
Copy link
Author

Ok I see thank you !

It's not really the scope of this issue but our workflow is to only have a single config file that both the CI (command line) and IDE (VS code) use.

This option would force us to commit a VS code settings file (or something like that ?). It's not a big deal but I'd rather have all the config in a single place. Also if Pyright ever works with other IDE it would force us to have one settings file per IDE to keep every body synchronized.

@erictraut erictraut changed the title Type of parameter "monkeypatch" is unknown with pytest and useLibraryCodeForTypes set to true Feature request: allow "useLibraryCodeForTypes" option to be set within config file Aug 10, 2020
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Aug 10, 2020
@erictraut
Copy link
Collaborator

This is addressed in Pyright 1.1.62, which I just published. It will also be included in the next version of Pylance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants