remove types_SQLAlchemy dependency

[Dr-Irv]

conda-forge build broke because types_SQLAlchemy is not a conda package. Apparently, it is automatically built from whatever is in typeshed.

Removing it to see if it passes CI.

[twoertwein]

Would moving it to the dev dependencies work?

[Dr-Irv]

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.

[twoertwein]

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).

[Dr-Irv]

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

[twoertwein]

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

[twoertwein]

Thank you @Dr-Irv