[Versioning] Migrate Hydra entry points to version_base 1.3 for Hydra 1.4 readiness

[theap06]

Prepares Hydra entry points for Hydra 1.4 (#4055)

• All hydra.main entry points and compose-API test calls now pass version_base="1.3" (previously "1.1", None, or unset).
• Configs of scripts that ran under 1.1 compat gain hydra.job.chdir: true, keeping run-dir behavior unchanged.
• hydra-core floor raised to >=1.3 in pyproject.toml.

Draft until Hydra 1.4 is released.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/rl/4056

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[theap06]

@omry left a PR addressing all the migrating all entry points.

[omry]

Thanks for putting this together. The migration is broadly consistent: all 57 @hydra.main entry points now pin version_base="1.3", the former 1.1-style applications receive hydra.job.chdir: true, and the updated Python and YAML files parse successfully.

One item to address is propagating the hydra-core>=1.3 floor to every first-party dependency manifest. The PR updates pyproject.toml, but several direct installation paths still use an unconstrained hydra-core or hydra-core>=1.1, including:

• examples/rlhf/requirements.txt
• sota-implementations/ppo-async/requirements.txt
• sota-implementations/grpo/requirements_gsm8k.txt
• sota-implementations/grpo/requirements_ifeval.txt
• docs/requirements.txt
• the SOTA CI dependency installation

In an existing environment, an unconstrained requirement can leave Hydra 1.1 installed. The new version_base="1.3" decorators would then fail during application startup.

One broader, non-blocking observation: needing to repeat hydra.job.chdir: true across 53 configurations suggests these entry points lack a shared base configuration for common Hydra behavior. The explicit additions are fine for this migration, but consolidating shared settings into a base config included through the defaults list could reduce duplication and prevent drift during future migrations. That could be handled separately.

There is also a broader compatibility choice to make. The new requirement is hydra-core>=1.3, so it will allow Hydra 1.4, while version_base="1.3" only preserves the behaviors controlled by that setting. It does not protect TorchRL from other Hydra 1.4 or OmegaConf changes. Examples include native tuples becoming TupleConfig rather than ListConfig, changes to hydra.utils.instantiate() resolution and container semantics, and different handling of call-site dataclass or attrs instances.

I suggest choosing one of these approaches:

• Add a CI job against the current Hydra 1.4 development release to detect broader incompatibilities; or
• Temporarily constrain the dependency to hydra-core>=1.3,<1.4, then remove the ceiling once Hydra 1.4 is sufficiently finalized and TorchRL’s compatibility has been validated.

The current state—allowing Hydra 1.4 without testing it—leaves users exposed to incompatibilities outside the scope of version_base.

[theap06]

@omry I just temporarily constrained the dep for now. once the 1.4 is finalized and the trl compability has been validated, I will draft a follow up pr for the updated dep.