Improves import times by delaying imports when needed

[bsignoret]

In some places, imports can be moved for faster loading times.

Example

On my computer, here's the result (it's not a precise measurement):
python -X importtime -c "from prefect import Runner"

before:

import time: 230957 | 1496253 | prefect

after:

import time: 215386 | 828572 | prefect

Checklist

• This pull request references any related issue by including "closes <link to issue>"
  • If no issue exists and your change is not a small fix, please create an issue first.
• If this pull request adds new functionality, it includes unit tests that cover the changes
• This pull request includes a label categorizing the change e.g. maintenance, fix, feature, enhancement, docs.

For documentation changes:

• This pull request includes redirect settings in netlify.toml for files that are removed or renamed.

For new functions or classes in the Python SDK:

• This pull request includes helpful docstrings.
• If a new Python file was added, this pull request contains a stub page in the Python SDK docs and an entry in mkdocs.yml navigation.

[netlify]

👷 Deploy request for prefect-docs-preview pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	88deac8

[serinamarie]

@bunchesofdonald Are you able to comment on why this one is currently prefect.server? It seemed to be backwards compatibility for build_from_flow based on the PR I saw, but wanted to double check on it

[bunchesofdonald]

Yeah, essentially. Since we're doing an isinstance check we need to check against the server's version for that to work out, the client's version isn't the same instance. Having this behind a TYPE_CHECKING flag should be fine.

[serinamarie]

Okay, cool, what I'm hearing is that we should then probably do:

if TYPE_CHECKING:
    from prefect.server.schemas.schedules import SCHEDULE_TYPES

[bsignoret]

Hello!
Currently (Before this PR), we have:

from prefect.client.schemas.schedules import SCHEDULE_TYPES

SERVER_SCHEDULE_TYPES (prefect.server.schemas.schedules) is only used to raise an error.

Why would we want to replace this line with the server version?
Is the current code no good?

[serinamarie]

@bsignoret Ah, no that's not what I meant, I meant in addition to that, but looking further, keeping it behind TYPE_CHECKING won't work anyway.

However, I think we could simplify this with reflecting type checking like so:

is_server_schema = obj.__class__.__module__ == "prefect.server.schemas.schedules"
if is_server_schema:
    raise ValueError(
        "Server schema schedules are not supported. Please use "
        "the schedule objects from `prefect.client.schemas.schedules`"
    )

Then we can avoid importing any server-side schema. Would you be willing to give that a shot? Tests passed for me locally with that change.

[bsignoret]

Thank you for your idea. I've just made the modification and tests are also passed on my side.

[serinamarie]

Nice! I'm running our workflows again, and if they pass, I think to future-proof against schedule module name changes and to make it more generic, we probably want to change this last line:
return obj.__class__.__module__.startswith("prefect.server.schemas")

[serinamarie]

Sorry, hope you don't mind but I'd love to get this in for Thursday's release, so I made this change in cc8dde8

[serinamarie]

Hi @bsignoret, thanks for opening your first PR(s) with Prefect!

Appreciate these improvements, we were currently working on that this week so it's great timing.

You can fix the failing tests intests/utilities/test_visualization.py by changing this line:
"prefect.flows.visualize_task_dependencies", MagicMock(return_value=None)
to
"prefect.utilities.visualization.visualize_task_dependencies", MagicMock(return_value=None)

at lines 259 and 334.

Additionally, I think you'll need to actually import the client side schedule type schema in the create_minimal_deployment_schedule function:
from prefect.client.schemas.schedules import SCHEDULE_TYPES

I pulled your branch and confirmed that the failing tests pass with those changes, so provided you get a chance to make those changes we can run the workflows here again and see if there's anything else left to fix to get this through!

[bsignoret]

Thanks for your feedback!
I've just fixed the failed tests. I've run the tests again on my side, and it looks good now.

However, I'm not sure I understand this modification:

Additionally, I think you'll need to actually import the client side schedule type schema in the create_minimal_deployment_schedule function:
from prefect.client.schemas.schedules import SCHEDULE_TYPES

[serinamarie]

Thanks for your feedback! I've just fixed the failed tests. I've run the tests again on my side, and it looks good now.

However, I'm not sure I understand this modification:

Additionally, I think you'll need to actually import the client side schedule type schema in the create_minimal_deployment_schedule function:
from prefect.client.schemas.schedules import SCHEDULE_TYPES

Hi @bsignoret, after chatting with @bunchesofdonald I think that we want to still keep the server schema but put it behind the TYPE_HINTING condition, like in my comment

[serinamarie]

I think moving this here may be causing the failing tests but haven't checked

[serinamarie]

Hope you don't mind, I'd love to get this in so I'm fixing these failing tests

[serinamarie]

Update:
Removing the server import (the schedule schema) uncovered some persistent runner tests failures:

• test_runner_executes_flow_runs
• test_runner_can_execute_a_single_flow_run
• test_runner_respects_set_limit

In order to resolve these, I put up a PR to defer an import that was importing, among other things, EventPersister, leading to a runtime error.

Defer import of temporary_database_interface in testing utilities

As well as a PR to Lazily instantiate asyncio.Event in EventPersister for context safety to ensure if we do end up importing the event_persister module in other modules/use it in other tests, we won't run into this same error in the future.