This moves Hydra away from rigid inheritance trees (which often broke) toward a more flexible composition model. You can now write:
Last week, the team released , and it is not just a minor patch—it changes how we think about configuration composition. hydra 1.2
Version 1.2 introduces for certain resolver functions. Early benchmarks show a 40% reduction in instantiation time for large config suites. 5. Deprecation of hydra.main This is the breaking change you need to watch for. The decorator @hydra.main() has been a staple since day one. It now throws a DeprecationWarning . In Hydra 2.0 (planned for Q3 2026), it will be removed. This moves Hydra away from rigid inheritance trees
If you have ever tried to manage a massive Python configuration file full of nested dictionaries, you know the pain. That is why the open-source community fell in love with (from Facebook Research). It allows you to compose dynamic configurations from multiple files and override anything from the command line. Early benchmarks show a 40% reduction in instantiation
pip install hydra-core --upgrade Happy composing! Let us know in the comments if you have found the 1.2 resolver syntax tricky—I will be writing a deep dive on that next week.
defaults: - storage: aws - optional region: ${storage.region} Hydra was notorious for adding 200–400ms to script startup time because it parsed every @dataclass and OmegaConf structure recursively. For long-running training jobs, this didn't matter. For serverless functions or CLIs? It hurt.
# Old (Hydra 1.1) @hydra.main(config_path="conf", config_name="config") def main(cfg): ... def main(): cfg = hydra.initialize_and_run(config_path="conf", config_name="config", task_function=my_task)