Proposal
The current isort configuration reorders imports in a way that merges standard library modules with pip-installable dependencies, and applies custom grouping logic across multiple package families.
While this works from a tooling perspective, it diverges from what most Python users expect when reading code.
One possible direction would be to realign the default import structure with the standard three-block convention, while limiting special-case handling to packages that are genuinely runtime-provided (e.g. isaacsim, omni, carb, etc.).
This would keep most imports predictable and familiar, while still allowing flexibility where runtime constraints require it.
Motivation
Reordering imports can be helpful in a limited set of scenarios, most commonly to mitigate circular import issues. In practice, however, frequent reliance on import reordering often points to deeper package design concerns. While reordering can work around symptoms, it does not address underlying structural issues.
Even if circular imports are not a concern in this specific case, the current import grouping introduces cognitive overhead. From a Python user’s perspective, the widely understood and de-facto standard convention is:
- Standard library imports
- External dependencies (declared in pyproject.toml)
- Internal / local modules
This structure makes it easier to:
- Reason about dependencies
- Spot missing or undeclared dependencies
- Quickly understand where a symbol comes from
- Onboard new contributors
Build Info
- Isaac Lab Version: main
- Isaac Sim Version: N/A
Additional context
This issue is intended to start a discussion around balancing:
- Tooling consistency
- Runtime constraints
- Readability and developer expectations
Original discussion started here: #3619
Checklist
Acceptance Criteria
Proposal
The current
isortconfiguration reorders imports in a way that merges standard library modules with pip-installable dependencies, and applies custom grouping logic across multiple package families.While this works from a tooling perspective, it diverges from what most Python users expect when reading code.
One possible direction would be to realign the default import structure with the standard three-block convention, while limiting special-case handling to packages that are genuinely runtime-provided (e.g.
isaacsim,omni,carb, etc.).This would keep most imports predictable and familiar, while still allowing flexibility where runtime constraints require it.
Motivation
Reordering imports can be helpful in a limited set of scenarios, most commonly to mitigate circular import issues. In practice, however, frequent reliance on import reordering often points to deeper package design concerns. While reordering can work around symptoms, it does not address underlying structural issues.
Even if circular imports are not a concern in this specific case, the current import grouping introduces cognitive overhead. From a Python user’s perspective, the widely understood and de-facto standard convention is:
This structure makes it easier to:
Build Info
Additional context
This issue is intended to start a discussion around balancing:
Original discussion started here: #3619
Checklist
Acceptance Criteria