[Scene] Deprecate InteractiveSceneCfg.clone_in_fabric

[hujc7]

Summary

Follow-up to #5437 addressing @ooctipus's comment: #5437 (comment)

InteractiveSceneCfg.clone_in_fabric is dead. The field is declared on InteractiveSceneCfg, passed through to TemplateCloneCfg at scene init, and never read by any physics backend — verified by grepping every *_physx, *_newton, *_ovphysx, *_ov package: zero hits. Setting clone_in_fabric=True today has no effect on cloning.

This PR deprecates the field per AGENTS.md's breaking-change rule (deprecate first, remove in a later release).

Behavior

• Field type, default, and existing callers are unchanged.
• Setting clone_in_fabric=True now emits a DeprecationWarning from __post_init__ and the field is reset to False before scene init proceeds (so re-runs via configclass.replace don't double-warn).
• Setting clone_in_fabric=False (the default) is silent — matches the previous behavior.

Out of scope (for later cleanup)

• Removal of the field itself (deprecation period must elapse).
• Cleanup of the ~14 isaaclab_tasks env-cfg sites that currently set clone_in_fabric=True (they're no-ops today; will trigger the new warning until the field is removed).
• TemplateCloneCfg.clone_in_fabric (internal-only; downstream of InteractiveSceneCfg).

Test plan

• Existing test_simulation_stage_in_memory.py / test_environments_with_stage_in_memory.py continue to pass.
• Manual smoke: construct an env with clone_in_fabric=True and confirm the DeprecationWarning fires.

[isaaclab-review-bot]

Review: Deprecate InteractiveSceneCfg.clone_in_fabric

Clean deprecation implementation. The approach is sound:

What's good:

• Follows deprecation-first pattern correctly (warn now, remove later)
• Deprecation warning only fires on True (the problematic value), not on default False
• Resetting to False after warning prevents double-warn on configclass.replace — nice touch
• stacklevel=2 is correct for warning from __post_init__
• Changelog is clear and actionable
• Good audit trail in PR description (verified no backend reads the field)

One minor note:

• The version tag .. deprecated:: 4.6.23 in the docstring — is that the actual target version? Just flagging in case it's a placeholder.

LGTM ✅ — straightforward deprecation, no functional risks.

[greptile-apps]

Greptile Summary

This PR deprecates InteractiveSceneCfg.clone_in_fabric by adding a __post_init__ that emits a DeprecationWarning and resets the field to False when it is set to True, following the project's deprecate-before-remove policy for a field confirmed to be a no-op across all physics backends.

• interactive_scene_cfg.py: adds __post_init__ with the deprecation warning, field reset, and an updated docstring with .. deprecated:: 4.6.23; the existing ~14 task configs that set clone_in_fabric=True will now emit warnings until the field is removed in a later release.
• changelog.d/jichuanh-deprecate-clone-in-fabric.rst: new changelog fragment documenting the deprecation and migration path.

Confidence Score: 4/5

Safe to merge; the deprecation logic is correct and the field reset works as intended.

The warning fires correctly and the field is properly reset. The only concern is that stacklevel=2 attributes the warning to a configclass-internal frame rather than the user's call site, which can cause Python's default DeprecationWarning filter to silently drop it in non-test runtimes.

source/isaaclab/isaaclab/scene/interactive_scene_cfg.py — the stacklevel value in the warnings.warn call.

Important Files Changed

Filename	Overview
source/isaaclab/isaaclab/scene/interactive_scene_cfg.py	Adds post_init to emit DeprecationWarning and reset clone_in_fabric=False when set to True; stacklevel=2 likely misdirects the warning to a configclass-internal frame rather than user code.
source/isaaclab/changelog.d/jichuanh-deprecate-clone-in-fabric.rst	New changelog fragment correctly documents the deprecation of clone_in_fabric with usage guidance.

Sequence Diagram

sequenceDiagram
    participant User as User Code
    participant Init as dataclass __init__
    participant Combined as _combined_function (configclass)
    participant PostInit as __post_init__ (InteractiveSceneCfg)
    participant CustomPost as _custom_post_init (configclass)

    User->>Init: "InteractiveSceneCfg(clone_in_fabric=True)"
    Init->>Combined: self.__post_init__()
    Combined->>PostInit: f1(self)
    PostInit-->>User: "warnings.warn(DeprecationWarning, stacklevel=2)"
    PostInit->>PostInit: "self.clone_in_fabric = False"
    Combined->>CustomPost: f2(self)
    CustomPost->>CustomPost: deepcopy all fields
    Combined-->>Init: return
    Init-->>User: "instance (clone_in_fabric=False)"

Loading

_{Reviews (1): Last reviewed commit: "Deprecate InteractiveSceneCfg.clone_in_f..." | Re-trigger Greptile}

[greptile-apps]

The stacklevel=2 inside __post_init__ is off by two frames because @configclass wraps the method with _combined_function. The actual call chain when a user constructs the object is: user_code → dataclass __init__ → _combined (configclass.py:513) → user __post_init__ → warnings.warn. With stacklevel=2 the warning is attributed to configclass.py:513 (a library-internal frame), not the user's call site. Python's default DeprecationWarning filter only shows the warning when it appears to originate from user code or __main__, so this misdirection can silently swallow the warning in production (non-pytest) environments. The correct depth to reach the user's call site is stacklevel=4. Note: the existing ViewerCfg.__post_init__ in common.py has the same bug, so this is a latent pattern issue, but it's still worth fixing here to make the new deprecation reliably visible.

Suggested change

	warnings.warn(
	"InteractiveSceneCfg.clone_in_fabric is deprecated and will be removed in a future release."
	" The field is a no-op (no physics backend reads it); remove the kwarg.",
	DeprecationWarning,
	stacklevel=2,
	)
	warnings.warn(
	"InteractiveSceneCfg.clone_in_fabric is deprecated and will be removed in a future release."
	" The field is a no-op (no physics backend reads it); remove the kwarg.",
	DeprecationWarning,
	stacklevel=4,
	)

[AntoineRichard]

Hi @hujc7 — thanks for putting this one up! 🙏

We're doing a cleanup pass over the Isaac Lab PR backlog, which had grown past 400 open pull requests, and we're closing out the ones that have gone quiet so the queue is reviewable again.

Why this PR is being closed: Here is exactly what we found on this PR when we reviewed the backlog:

Opened	2026-05-12 (about 4 months ago)
Last commit on the branch	2026-05-12
Last activity from the author	about 4 months ago
Target branch	develop
Review status	Never reviewed by a maintainer — nobody on the team got to it. Sorry about that.
Merge status	Unknown
Size	1 commit(s), 2 file(s) changed, +27 / -9

It was picked up by the sweep because it has been open for about 4 months. It was then put in the "close" bucket because the author has been silent for about 4 months — which is the signal we used to tell apart pull requests that are still being worked on from ones that have genuinely been set aside.

We deliberately did not close pull requests that were approved and ready to land, or that were small and clearly still fixing a live bug — there were 27 of those, and we are merging them rather than closing them.

No judgement on the change itself — this is purely backlog hygiene.

If this is still wanted, please reopen it or re-submit against develop. 💚

---

🤖 This comment was drafted with AI assistance as part of a maintainer-led sweep of the Isaac Lab pull request backlog. A maintainer is behind this cleanup — but if this closure looks wrong, it may well be, so please push back and we'll take another look.