Client(transport=transport,fetch_schema_from_transport=True) returning None for schema v3.0.0a5

[funkwhatyouheard]

Trying to perform dynamic queries as in the documented example here: https://gql.readthedocs.io/en/v3.0.0a5/advanced/dsl_module.html#sync-example. When I try to instantiate the gql.Client() with fetch_schema_from_transport=True, the schema attribute is not populated for v3.0.0a5. Attempting this same action with v2.0.0, the schema is return successfully. Here's the neutered version of the code I'm attempting to run:

from gql import Client, gql
from gql.transport.requests import RequestsHTTPTransport
from gql.dsl import DSLSchema
transport = RequestsHTTPTransport(url=<url>,headers={"Content-Type":"application/json","Authorization":"Bearer <token>"},verify=False)
client = Client(transport=transport,fetch_schema_from_transport=True)
client.schema

[funkwhatyouheard]

Verified that this issue didn't exist in previous versions (checked 3.0.0a3 and 3.0.0a4). Thinking it was this commit 6254ab9#diff-e7077cd6b8587f1d6e5e8845e5b143e91364dbc2c1ca8e830010e2a75aadd6a7.

Need to dig into it more...

[leszekhanusz]

We changed when the schema is fetched, the reasons are explained in PR #167 .
This was also specified in the release notes of version 3.0.0a5

Please note that if you use the complete example from the docs https://gql.readthedocs.io/en/v3.0.0a5/advanced/dsl_module.html#sync-example, then it works correctly because we are using the schema only after the first session is done (after with client as session:)

It should be possible to reproduce the old previous behaviour by making a session in which you do nothing. By adding:

with client as session:
    pass

We should add a section in the docs on how to migrate from 2.0 to 3.0 which will explain in more details the breaking changes in 3.0

[funkwhatyouheard]

Ha. Ya know, probably should have gotten that from the documentation I didn't read thoroughly or from the commit message or the release notes. Just verified, pulling schema correctly. Sorry for the false alarm. 2.0 -> 3.0 breaking change would certainly be helpful, but my inattention to detail was the only issue in this case. :)