Skip to content

remove types_SQLAlchemy dependency #275

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Sep 6, 2022
Merged

remove types_SQLAlchemy dependency #275

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,6 @@ packages = [
[tool.poetry.dependencies]
python = ">=3.8,<3.11"
types-pytz = ">= 2022.1.1"
types_SQLAlchemy = ">=1.4.50"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would moving it to the dev dependencies work?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is needed either way. Don't fully understand why. Apparently types_SQLAlchemy is built from the typeshed repo, but only as a pip installer, and you can't have a conda installer depend on packages only available via pip.

We might be able to remove types-pytz as a dependency as well.

What I don't understand is that we have import sqlalchemy.engine in the stubs, so you'd expect that if it wasn't installed, the type checkers would complain about a missing import. And I don't have it installed in my environment now, nor do we install it when we do CI, yet we get no failures.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we would get failures if we enabled more strict settings. I think ignore_missing_imports = true would find these cases (and maybe other Any-related checks from mypy). Not sure why reportMissingImports doesn't trigger errros (maybe we need reportMissingTypeStubs).

These third-party stubs are probably only important if we specifically test whether to_sql accepts non-sql objects as an argument (if mypy/pyright don't know what the accepted type is, they will assume it is Any/Unknown).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we'd get the failures with ignore_missing_imports=true as well. If I turn on reportMissingTypeStubs, then we get complaints about matplotlib and excel related items.

I think it has to do with how either (or both) mypy and pyright use typeshed, where the types for SQLAlchemy are defined.

If you could approve/merge this PR, I will do a new release of the version I put on pypi yesterday

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it has to do with how either (or both) mypy and pyright use typeshed, where the types for SQLAlchemy are defined.

Make sense


[tool.poetry.dev-dependencies]
mypy = ">=0.971"
Expand Down