Lazy load neo4j driver imports

[Anuragp22]

Lazy-load neo4j SDK imports to reduce memory footprint and import time of airflow.providers.neo4j.hooks.neo4j, following the same pattern as #62365 (snowflake) and #67519 (elasticsearch).

Hook changes

• Removed the top-level from neo4j import Driver, GraphDatabase.
• Driver is only used as a type annotation, so it now lives under if TYPE_CHECKING:.
• GraphDatabase.driver(...) is only invoked inside _create_driver, so the import is moved into that method body.

Test changes

• Updated five mock.patch targets in test_neo4j.py from airflow.providers.neo4j.hooks.neo4j.GraphDatabase to neo4j.GraphDatabase (and ...GraphDatabase.driver for the parametrized test), since GraphDatabase is no longer a module-level symbol in the hook module.

Validation

Local smoke check (Windows host; full unit suite requires the Linux-only fcntl import that Airflow's test conftest pulls in transitively):

• Importing Neo4jHook no longer loads the neo4j package into sys.modules.
• Driver and GraphDatabase are no longer attributes of the hook module.
• neo4j.GraphDatabase and neo4j.GraphDatabase.driver resolve as mock.patch targets.

The unit tests in providers/neo4j/tests/unit/neo4j/hooks/test_neo4j.py should now pass against the moved import; CI will be the source of truth here.

• related: Provider package performance improvements via lazy loading 3rd party packages #67515

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude (Opus) was used for the mechanical edits and the announcement comment on Provider package performance improvements via lazy loading 3rd party packages #67515. Reviewed by hand against the pattern in Lazy load snowflake imports to improve performance #62365 and Lazy load Elasticsearch hook client import #67519.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[dwreeves]

Seems good to me. Thanks!

[kaxil]

Hi @Anuragp22, thank you for the focused work here -- the engineering on this PR is clean.

I'm closing this along with the other PRs targeting #67515 after thinking through the actual savings more carefully. Full reasoning here: #67515 (comment)

Short version: an Operator imports a Hook which imports the SDK, so moving the SDK import inside a method mostly shifts when the import happens rather than saving it -- workers running the task pay the same cost. It also loses the parse-time import_error surface that today reports install/version issues to users. PEP 810 (lazy imports, Python 3.15) is the cleaner path and the polyfill works alongside it without source-level refactors.

Genuinely sorry for the wasted cycles -- on us for not flagging the strategy concern before contributors started shipping.

Two areas that are worth the work if you want something else to pick up:

1. TYPE_CHECKING guards on type-only imports across providers. Pure win, no trade-off.
2. Lazy-loading conditionally-used heavy deps (e.g. pandas_gbq inside BigQueryHook.get_pandas_df rather than at module level) -- the fail-fast loss is scoped to methods users may never call.

Thanks again.