search

kevinheavey / solders

A high-performance Python toolkit for Solana, written in Rust
https://kevinheavey.github.io/solders/
Apache License 2.0
205 stars 23 forks source link

Why I am getting import problem? #31

Closed ashique992 closed 1 year ago

ashique992 commented 1 year ago

Hi Kevin,

I have import problem for solders. I am using Python 3.11.0 also i have tried 3.7 but same problem.

image image

Can you help me?

Thanks.

kevinheavey commented 1 year ago

What error message are you getting?

ashique992 commented 1 year ago

What error message are you getting?

Import solders could not be resolved from source Pylance

kevinheavey commented 1 year ago

Are imports from other libraries working fine in that file?

And does the solders import work fine at runtime?

kevinheavey commented 1 year ago

@ashique992 let me know if you have any more information. I'll close this in a few days

kevinheavey commented 1 year ago

Closing, feel free to reply and I'll reopen

thekeviv commented 1 year ago

@kevinheavey I also seem to be having the same issue. The other lib imports work fine.

image image
kevinheavey commented 1 year ago

@thekeviv Pyright complains about packages that are just Rust/C + .pyi files, such as Solders. Pyright still works fine and the complaining can be turned off, which I do by adding this to my pyproject.toml:

[tool.pyright]
reportMissingModuleSource = false

Do let me know if you encounter another way to prevent this.

thekeviv commented 1 year ago

Thank you for explaining. I wish it was possible to only turn that warning off for solders and not all modules but it doesn't seem like that's possible (unless you add # pyright: ignore next to imports).

raymondjacobson commented 1 year ago

+1 am seeing this as well. @thekeviv did you find any other solve?

Note that the vscode fix here is

"python.analysis.diagnosticSeverityOverrides": {
        "reportMissingModuleSource": "none"
    },
bhy commented 4 months ago

Hi, I just stumbled upon this issue and wanted to chime in on the root cause. If you look at the Python typing doc on module public symbols, it says the static type checking only understands a limited set of syntax for defining __all__. Since solders need to dynamically extend __all__, it may not be properly resolved.

kevinheavey commented 4 months ago

Thanks @bhy. Do you have any thoughts on just making __all__ include every module whether or not it's available on the user's platform? Not perfect but I'm wondering if that would be less disruptive for people

bhy commented 4 months ago

Thanks @bhy. Do you have any thoughts on just making __all__ include every module whether or not it's available on the user's platform? Not perfect but I'm wondering if that would be less disruptive for people

Yes. I think it makes sense to make __all__ static, since it is for checking code. When a module is not available, it could be an error raised at runtime during import, since that should be a building / configuration issue.