heavy Client instantiation required to run get_regions(), or to resolve SAPI endpoint (root cause: config parsing),
caching is not transparent and lacks control mechanisms (see #503, #506),
lacks a way to resolve leap_api_endpoint.
Proposed solution
Extract/re-implement the ad hoc Client methods for fetching Leap regions and resolving region code to SAPI endpoint into a new helper class, something like dwave.cloud.regions.RegionsRegistry.
RegionsRegistry should provide an interface to:
initialize with custom config, using client's config, or using the default config
control caching: change maxage, force refresh, turn caching off (#503)
resolve any region-dependent endpoint, i.e. endpoint/solver_api_endpoint and leap_api_endpoint for now.
Issue
The current implementation has several issues:
Clientinstantiation required to runget_regions(), or to resolve SAPIendpoint(root cause: config parsing),leap_api_endpoint.Proposed solution
Extract/re-implement the ad hoc
Clientmethods for fetching Leap regions and resolving region code to SAPI endpoint into a new helper class, something likedwave.cloud.regions.RegionsRegistry.RegionsRegistryshould provide an interface to:endpoint/solver_api_endpointandleap_api_endpointfor now.