Qlib’s region system parameterized

[maxilirator]

🌟 Feature Description

Make qlib’s region system fully parameterized so users can register and switch to non-us/cn markets (e.g., Nordics) without modifying core code. Region metadata (calendars, instruments, feature folders, filters) should be resolved dynamically from config/initialization parameters.

Motivation

Application scenario: Running qlib on Swedish equities via a custom qlib_ext_se package—today we must patch qlib internals because many components assume only us or cn.
Related works: qlib’s qlib_ext examples show how to add data packs, but they still depend on region-specific switches inside qlib.
Other info: We have local data under /data/xsto with its own calendars/instruments. We can initialize qlib_ext_se, but key subsystems (e.g., config.C["region"], filters, default provider URIs) only recognize the built-in regions, so we end up hacking global constants.

Alternatives

Maintain a fork that overrides region-specific modules, but this diverges from upstream and complicates upgrades. Another approach is to masquerade as us or cn, but that pollutes calendars/instrument sets and defeats the purpose of regional metadata.

Additional Notes

A more flexible region system could expose hooks or registration APIs for external packages: declare region name, calendar file paths, instrument configs, and default providers. That would let communities publish regional data packs that “just work” with qlib.init(region="se", provider_uri=...).

[SunsetWolf]

Hi, @maxilirator

Thanks for the detailed suggestion!

From the current Qlib implementation, it is actually possible to extend regions without modifying the core code.

The existing mechanism already supports extension through configuration.

You can simply add your custom market configuration directly into the _default_region_config structure in the config settings.