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

VSCode (with jedi) can't suggest imports beyond base level of package #1457

Open
xxkennyxu opened this issue Feb 2, 2024 · 5 comments
Open
Labels
auto-triage-skip question M-T: User needs support to use the project Version: 3x web-client

Comments

@xxkennyxu
Copy link

I'm trying to import classes defined in the SDK but for some reason it won't suggest imports beyond:

  • WebClient
  • WebhookClient

The imports I am looking for are SlackResponse, any of the Block classes (SectionBlock, ...) . If I manually import them they work fine and if I run pip list, slack-sdk shows up correctly.

Any ideas?

The Slack SDK version

slack-bolt==1.18.1
slack-sdk==3.26.1
slack-webhook==1.0.3

Python runtime version

Python 3.8.13

ProductName: macOS
ProductVersion: 13.1
BuildVersion: 22C65
Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000

Steps to reproduce:

image
image

Expected result:

I'd expect the SectionBlock suggestion to show up.

Actual result:

See previous screenshots

Requirements

For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

@seratch seratch added question M-T: User needs support to use the project web-client Version: 3x and removed untriaged labels Feb 5, 2024
@seratch
Copy link
Member

seratch commented Feb 5, 2024

Hi @xxkennyxu, thanks for writing in. This seems to be a limitation on the lang server integration with VS Code. If this project add all possible module names into __all__ variable in https://github.com/slackapi/python-slack-sdk/blob/main/slack_sdk/__init__.py , perhaps more names will show up. However, some of the class/type names can conflict, plus even if there is no name conflict, it brings more maintainance cost to this project. Thus, we hesitate to make such changes.

If you need a more intelligent code editor, one great option would be PyCharm IDE: https://www.jetbrains.com/pycharm/ I've been a PyCharm user for a long time, and it does not have the issue you mentioned here. PyCharm Professional requires a paid license, but when you don't use it for work, the community edition (free) is also available.

I hope this helps.

@eddyg
Copy link
Contributor

eddyg commented Feb 5, 2024

Hi Kaz!

As a heavy user of VS Code, I wanted to jump in and provide a bit of info.

First, let me just say I’m not a fan of the __all__ approach; it exists to define the symbols that should be imported when using a wildcard import.

The problem stems from the fact that Python doesn't have keywords like public, private or export to allow devs to be explicit about access control. One of the “solutions” to this is defined in PEP-484: redundant imports. This is how pyright and pylance (used by VS Code) determine if something is “public” and available for Intellisense. Redundant imports are also supported by mypy and ruff (flake8 uses __all__).

I recently saw redundant imports in dilib if you want to see an example.

All that being said, adding and maintaining all the appropriate redundant imports would still be significant!

@WilliamBergamin
Copy link
Contributor

WilliamBergamin commented Feb 6, 2024

Thanks for the knowledge @eddyg, I was not aware about the stub file "solution"

Have you seen this implemented alongside the __all__ approach, wondering if we could be added it in without impacting users

@eddyg
Copy link
Contributor

eddyg commented Feb 9, 2024

I can't think of any projects where I've seen both redundant imports and __all__. According to Kaz's comment above, he is hesitant to add more things to __all__ since it will bring "more maintainance cost to this project". (And as I mentioned, I see __all__ encouraging wildcard imports, which in my opinion should be avoided). But keeping redundant imports updated would also add extra maintenance costs to this project as well. My comment was to mostly intended to provide insight into how VS Code finds "public" Python code.

Copy link

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-triage-skip question M-T: User needs support to use the project Version: 3x web-client
Projects
None yet
Development

No branches or pull requests

4 participants