potiuk commented on code in PR #74169:
URL: https://github.com/apache/airflow/pull/74169#discussion_r4177982954
##########
providers/amazon/src/airflow/providers/amazon/aws/executors/batch/utils.py:
##########
@@ -29,14 +29,14 @@
from airflow.providers.amazon.version_compat import AIRFLOW_V_3_3_PLUS
if AIRFLOW_V_3_3_PLUS:
- from airflow.executors.workloads.types import WorkloadKey
+ from airflow.executors.workloads.types import WorkloadKey as
_BatchWorkloadKey
- BatchJobWorkloadKey: TypeAlias = WorkloadKey
+ BatchJobWorkloadKey: TypeAlias = _BatchWorkloadKey
Review Comment:
It's a bitch catch 22. We could do it at once when migrating to 3.11 and new
sphinx, but that would make the 3.11 migration bigger and spanning more stuff.
This one is needed to support both 3.10 j+ sphinx 8 as well as 3.11 + Sphinx 9
> It's purely a Sphinx workaround; at runtime nothing changes. The rename
has to satisfy both docs builds at once (Python 3.10 / Sphinx 8.1.3 and Python
3.11 / Sphinx 9.0.4):
Sphinx 9 (why it can't stay WorkloadKey). Sphinx 9 resolves annotation types
project-wide. When autodoc renders BatchJobWorkloadKey: TypeAlias =
WorkloadKey, the bare name WorkloadKey matches the same-named aliases
documented in the ECS and Lambda executor modules. That gives an ambiguous
cross-reference, which fails the docs job. CommandType had the same problem,
which is why it also became an explicit TypeAlias.
Sphinx 8 (why it can't be _WorkloadKey). Sphinx 8 registers the canonical
target of a documented type alias as an object of its own. The Lambda executor
already imports the core type as _WorkloadKey, so reusing that name in batch
would produce the same canonical name twice. That causes a "duplicate object
description" failure, which only shows up on 3.10. This is what the second
commit fixed.
So the import needs a name that is unique per module. _BatchWorkloadKey
follows the pattern the ECS executor already uses with _EcsWorkloadKey.
I guess we can remove it after we migrate to 3.11.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
