Update SQLAlchemy import path

[antonymilne]

Closes #1244. As @astrojuanlu correctly observed, we haven't actually gotten rid of the deprecation warning, we just pinned the version. This alters the import path to actually fix it.

In fact, the version was already pinned before: #1222 didn't really do anything because the version specifier ~=1.4 is essentially the same as >=1.4, <2.0. So I'm just reverting that to the ~= we had before, because it's more common in our codebase. Looking at the SQLAlchemy migration guide we could unpin this completely and just do >=1.4 but I've left the pin there for now just to be on the safe side (in general, I'd like to move towards more open-ended upper bounds, but that's for another time).

[astrojuanlu]

Thanks @AntonyMilneQB! Changes LGTM

[jmholzer]

Looks good, did you do a manual check that the deprecation warning is gone after these changes?

[antonymilne]

@jmholzer yep, I did and it's gone.

[astrojuanlu]

so, as @AntonyMilneQB spotted, there seems to be a problem with the types:

package/kedro_viz/models/experiment_tracking.py:11: error: Module "sqlalchemy.orm" has no attribute "declarative_base"  [attr-defined]

(and then a bunch of errors that cascade from there). This is essentially an instance of dropbox/sqlalchemy-stubs#250.

On the other hand, sqlalchemy 2.0 started shipping its own types sqlalchemy/sqlalchemy#6810 and I think sqlalchemy.orm is already covered, but we can't switch to it just yet.

The options are:

• don't do anything until we upgrade to sqlalchemy 2.0. users will keep seeing the deprecation warning. the other problem is that this would require "jumping" version without a smoother transition path.
• # type: ignore this error until we upgrade to sqlalchemy >= 2.0. introduces a small amount of risk because we would be "blind" to type errors around this area for a while. hopefully there are unit tests for it though?
• not sure there's a third option.

[antonymilne]

I find the warning sufficiently annoying that I think we should prioritise getting rid of it, since it appears not just when you run kedro viz but also when you run kedro jupyter commands if you have kedro-viz installed (due to the run_viz line magic being registered). Hence I'd be in favour of option 2. Risk of introducing bugs as a result of this seems very low, but we should keep an eye on sqlalchemy-stubs so that if there's a fix we can remove the ignore.