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

[BUG] Imports fail on latest 3.0.1 release #48

Closed
orf opened this issue Sep 3, 2020 · 2 comments
Closed

[BUG] Imports fail on latest 3.0.1 release #48

orf opened this issue Sep 3, 2020 · 2 comments
Labels
🐞 bug Something isn't working 🎉 released Changes were included to the latest release 👋 response needed Awaiting response from a reporter

Comments

@orf
Copy link

orf commented Sep 3, 2020

Describe the bug
It's not clear from the latest 3.x release notes if this is intended, but it seems mypy_boto3_[service].client modules have been removed. The boto3-stubs package still recommends importing it like this.

To Reproduce
Steps to reproduce the behavior:

  1. Install 'boto3-stubs[glue]'
  2. Run the following code snippet:
from mypy_boto3_glue.client import GlueClient
  1. Actual mypy output
    from mypy_boto3_glue.client import GlueClient
ModuleNotFoundError: No module named 'mypy_boto3_glue.client'

Expected mypy-output

No error I guess

Additional context

MacOS or Linux, tested on Py 3.7 and 3.8.

@orf orf changed the title [BUG] Imports fail on latest 3.x release [BUG] Imports fail on latest 3.0.1 release Sep 3, 2020
@vemel vemel added the 🐞 bug Something isn't working label Sep 4, 2020
@vemel
Copy link
Collaborator

vemel commented Sep 4, 2020

Thank you for the report!

New version that fixes this issue should be published to PyPI in a few minutes.

Unfortunately, I completely overlooked that pyi files are not importable, so imports were broken during adding pyright support. Also, I removed all type annotations from integration tests, so the release was broken. I re-added type annotations to s3 test.

The solution was hacky, but it works - all service packages contain py files identical to pyi. This means, packages are twice as big now, but mypy and pyright work exactly the same with explicit and implicit type discovery. I hope that type checkers will not go crazy because of py/pyi overlap.

Please let me know if the fix works for you.

@vemel vemel added 🎉 released Changes were included to the latest release 👋 response needed Awaiting response from a reporter labels Sep 4, 2020
@orf
Copy link
Author

orf commented Sep 7, 2020

Yes! This fixed it. Thank you @vemel!

@orf orf closed this as completed Sep 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working 🎉 released Changes were included to the latest release 👋 response needed Awaiting response from a reporter
Projects
None yet
Development

No branches or pull requests

2 participants