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

Robust handling of nested field. #37

Open
jperkelens opened this issue Mar 25, 2020 · 0 comments
Open

Robust handling of nested field. #37

jperkelens opened this issue Mar 25, 2020 · 0 comments

Comments

@jperkelens
Copy link
Contributor

Currently, the _find method resolves config values in priority order. However, it does not treat nested value robustly. Plenty of work has been done to support env binding support for nested config values. However, overrides & defaults will not respect nesting unless retrieved from the level in which they were set.

Example:

config:
     file_settings:
          name: cool_file
          permissions: rw
vyper.read_in_config(config.yaml)
vyper.set_default("config.file_settings.extension" , "txt")
vyper.set("config.file_settings.permissions" , "r")

vyper.get("config.file_settings.extension") # Returns: "txt"
vyper.get("config.file_settings.permissions") # Returns: "r"
vyper.get("config.file_settings") # Returns: { name: cool_file, permissions: rw }

The complexity of managing this in the _find method seems untenable and the library seems to be calling for some sort of composable, self referential construct built on config read to handle this appropriately. These are nascent thought but I'll try to work through a POC over the weekend.

tioxy added a commit to bataclanofficial/botaclan-archives that referenced this issue May 15, 2020
Generate automatically environment variables instead of manual binding.
This fixes a random bug described in:
- alexferl/vyper#37
- alexferl/vyper#31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant