Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to "hint" config options from user-code without hard override of the user environment config #425

Closed
randomir opened this issue Sep 2, 2020 · 0 comments · Fixed by #427
Assignees
Labels

Comments

@randomir
Copy link
Member

randomir commented Sep 2, 2020

With the current 3 layers to provide config options (like solver or endpoint):

  1. config file (all options)
  2. environment variables (limited set of options)
  3. keyword arguments to Client's constructor and from_config (all options)

it is impossible to "suggest" default option values (e.g. solver), but allow for user to override it on any of the 3 layers. Possible use cases:

  • user wants to set a soft default in code (layer 3), but allow override from environment
  • 3rd party library has a notion of preferred defaults, but wants to allow an easy override for its users

Proposal: implement a mechanism to provide config options on layer zero -- a per-Client instance default value for each config option, provided on construction.

For example, adding defaults argument to Client constructor and from_config, which would .update the Client class-level defaults for all accepted config options. Additional benefits of this are: consolidation of the defaults, clearly documenting all accepted config options in one place. It can be nicely combined with #357.

@randomir randomir self-assigned this Sep 2, 2020
randomir added a commit to randomir/dwave-cloud-client that referenced this issue Sep 20, 2020
Core functionality of dwavesystems#425.

Note: compatibility break -- Client init now takes ONLY THREE positional
arguments (endpoint, token, solver). In the future, we want to deprecate
pos args completely.

This compat break should have **minimal** impact. Legacy code used to
provide only endpoint and token via pos args.
randomir added a commit that referenced this issue Sep 22, 2020
Changes since 0.7.7:

New Features
---

- `Client` instance defaults via `defaults` constructor argument (#425)
- `Client` class defaults in `Client.DEFAULTS`
- Parsing of boolean options in configuration files. `on`/`off`,
  `true`/`false`, `1`/`0` all work as expected (#113)
- `@deprecated` utility decorator
- `aliasdict` utility `dict` subclass enabling lazy access to alias keys

Fixes
---

- Documentation refactor and update

Changes
---

- Removed legacy config file format (`.dwrc`) support (#138)
- Removed some of the deprecated `Solver.is_*` properties
- Removed support for deprecated formats: `bqm-ref` and `bq-zlib`.
- Removed support for more than first three positional arguments in
  `Client` constructor (`endpoint`, `token` and `solver`). Positional
arguments in the constructor will be deprecated eventually.
- `Client.solvers` scheduled for removal in 0.9.0
- Deprecated `Future.occurrences` in favor of `Future.num_occurrences`
- Deprecated `samples` and `occurrences` keys in
  `Future`/`Future.result()`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant