Hi all, we are getting the error from dagit and dameon.

cannot import name '_BindParamClause' from 'sqlalchemy.sql.expression

so we are running dagster version 0.15.10. just 4 days before it was fine and for the installation of dagit it was using sqlalchemy=1.4.46 version. Now suddenly it jumped to version 2.0.0 which I think is causing problem. any hints to solve this would be great 🙂

Hi zafar - we are rolling out a new release with a pin later today that will address this. For now installing dagster with sqlalchemy<2.0.0 should work as a workaround

so would you release this change for dagster version =0.15.* ? or the latest one ?

The release that’s coming out today is for the latest one (1.1.14) - we may follow with one for earlier versions, I’m not completely sure yet

😕 our pipelines are running on the old version at the moment

Is applying that workaround for a while an option? (Including "sqlalchemy<2.0.0" in your pip installs) i'd expect it to just work going forward with that applied

we are just testing that at the moment

this is helpful. thanks!

Oof. My team just updated one of our libraries today to 2.0 and so now we're experiencing problems. Currently using the helm release and it seems fine with the install (doesn't complain about version conflict) but jobs fail when they query for the run id.

The most recent version of dagster has a pin in it that should keep this issue from happening - pinning sqlalchemy yourself in your user code deployment should also work if you don’t want to upgrade dagster

Does dagster run in a separate environment when the job launches? Pretty sure if user code pins to 2.0 dagster will fail when it initializes inside the job container unless I'm off about the architecture.

Sorry when I said pinning sqlalchemy in your user code I meant pinning it to <2.0.0 - are you using a library that already depends on being on version 2.0?

Yes, but it's possible to reverse. Team already adapted a library to 2.0 when they saw the errors.

I see - at some point I’m sure we’ll make dagster sqlalchemy 2.0 compatible, but in the short term I think your best bet is staying on sqlalchemy 1

Yes, I guess that's the path of least resistance. What's the likely future plan? Triage implementations based on import versioning?

In the medium term I could imagine supporting both versions with some kind of shim