Skip to content

Conversation

@elbamit
Copy link
Contributor

@elbamit elbamit commented Jan 7, 2026

📝 Description

This is a following PR of #9121 that fixes a circular import in the runtime module and removes the need for function-level import.

RuntimeKinds was moved into a dedicated module (mlrun/runtimes/constants.py) so it can be imported without pulling in nuclio runtime modules. The nuclio resolver helpers (resolve_nuclio_runtime / resolve_nuclio_sub_kind) cannot live in constants.py because they depend on nuclio runtime classes (e.g. RemoteRuntime), which import base.py and create an import cycle.

To preserve backwards compatibility, the resolvers remain available as:
RuntimeKinds.resolve_nuclio_runtime and RuntimeKinds.resolve_nuclio_sub_kind,
implemented in mlrun/runtimes/__init__.py and attached as staticmethods.


🛠️ Changes Made

  • Moved RuntimeKinds to mlrun/runtimes/constants.py
  • Removed nuclio-related imports from constants.py to avoid import cycles
  • Implemented nuclio resolver helpers in mlrun/runtimes/__init__.py
  • Kept the existing RuntimeKinds.resolve_nuclio_* API working via staticmethod assignment

✅ Checklist

  • I updated the documentation (if applicable)
  • I have tested the changes in this PR
  • I confirmed whether my changes are covered by system tests
    • If yes, I ran all relevant system tests and ensured they passed before submitting this PR
    • I updated existing system tests and/or added new ones if needed to cover my changes
  • If I introduced a deprecation:

🧪 Testing


🔗 References


🚨 Breaking Changes?

  • Yes (explain below)
  • No

🔍️ Additional Notes

@elbamit elbamit requested a review from a team as a code owner January 7, 2026 15:03
Comment on lines 88 to 89
RuntimeKinds.resolve_nuclio_runtime = staticmethod(resolve_nuclio_runtime)
RuntimeKinds.resolve_nuclio_sub_kind = staticmethod(resolve_nuclio_sub_kind)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a good practice. move it to constants.py . I dont see a reason why not to put these functions under runtime class. if you need, use them as helper functions but make sure callees call these functions directly and not via the class overload functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nuclio resolver helpers (resolve_nuclio_runtime / resolve_nuclio_sub_kind) cannot live in constants.py because they depend on nuclio runtime classes (e.g. RemoteRuntime), which import base.py and create an import cycle.

…KindsBase class from constants.py. This keeps constants.py free of nuclio runtimes imports to avoid cycles, while not breaking BC of the nuclio resolver helper functions
@elbamit elbamit requested a review from liranbg January 8, 2026 08:21
…solute path instead of relatives in required files
@elbamit elbamit requested review from a team and TomerShor as code owners January 8, 2026 10:49
@liranbg liranbg merged commit 2a93333 into mlrun:development Jan 8, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants