Prepare docs for July 2023 wave of Providers

[eladkal]

Providers wave for July.

open issues:

• can not prepare common.sql provider due to openlineage, common.sql: provide OL SQL parser as internal OpenLineage provider API #31398 (comment)

[potiuk]

Rebased after Pydantic < 2.0.0 limit merged

[eladkal]

Rebased after Pydantic < 2.0.0 limit merged

Thanks! The release wave is still on hold till we figure out the open issue of common.sql

[potiuk]

Thanks! The release wave is still on hold till we figure out the open issue of common.sql

Which one ?

[eladkal]

Which one ?

The OL extra added to common.sql
#31398 (comment)

[potiuk]

As explained in #31398, I think there are fundamentally no problems with releasing the change with openlineage extra.

Our tests are passing (which also means that there are no imports that will not work becasue of openlineage missing (currently we do not install openlineage provider during tests) - so we have quite a certainty that not having openlineage provider is going to work fine for common.sql

[eladkal]

As explained in #31398, I think there are fundamentally no problems with releasing the change with openlineage extra.

Our tests are passing (which also means that there are no imports that will not work becasue of openlineage missing (currently we do not install openlineage provider during tests) - so we have quite a certainty that not having openlineage provider is going to work fine for common.sql

I think releasing an extra that you can't install is not like installing a provider with a feature that isn't useable yet and the code tells you that you can't use it (like we did with Notifiers being released in providers before we released it in core) but If others consider it as OK I will proceed with the release

[potiuk]

I think releasing an extra that you can't install is not like installing a provider with a feature that isn't useable yet and the code tells you that you can't use it (like we did with Notifiers being released in providers before we released it in core) but If others consider it as OK I will proceed with the release

I think we won't avoid it at times - sometimes we even deliberately released something that was not usable so that we could refer to it in the future. Not ideal, but this is sometimes inevitable when we have two independent things being developed/released when usage of one will depend on the other.

But if it bothers you, I can draft a very small PR to exclude it.

[potiuk]

PR: here: #32325

You will have to regenerate the docs (specficially common.sql) after merging and rebasing on top of this one @eladkal

[eladkal]

After discussing with @potiuk I'll continue with the release as is

[eladkal]

Looks like there is issue with MsSQL tests

[potiuk]

Looks like there is issue with MsSQL tests

Likely #32343 should fix main ( guess it's the sqlalchemy refactor).