✅ Deploy Preview for dynaconf ready!

Name	Link
🔨 Latest commit	5d073e2
🔍 Latest deploy log	https://app.netlify.com/sites/dynaconf/deploys/6489f1e633d4d0000835e456
😎 Deploy Preview	https://deploy-preview-939--dynaconf.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Codecov Report

Merging #939 (5d073e2) into master (ab71181) will decrease coverage by 0.10%.
The diff coverage is 99.37%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master     #939      +/-   ##
==========================================
- Coverage   99.89%   99.79%   -0.10%     
==========================================
  Files          21       22       +1     
  Lines        1844     1976     +132     
==========================================
+ Hits         1842     1972     +130     
- Misses          2        4       +2     

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Dynaconf inspect CLI sub-command takes a key name (or dotted path) and outputs,
we have to keep it in conformity with existing CLI commands such as list so the options you listed are right.

$ dynaconf inspect --help
Usage: dynaconf inspect [OPTIONS]

Inspect the current value and loading history for settings.

Options:
    -k, --key TEXT            Filters a single key
    -e, --env string          filter by environement. Eg: development
    -f, --format string       output format: json, yaml, table (default: table)
                              "table": prints the output to stdout     
    --help                    Show this message and exit.

$ dynaconf inspect -k foo -f json
{
    "current": ...,
    "history": ...,
}

To save a file users can pipe the results or redirect stdout

dynaconf inspect -k foo -f json | jq
dynaconf inspect -k foo -f json > file.json

If -k is omitted then it dumps all defined keys, this would be useful to grep for filenames.

Programmatically the inspect function can take key as optional, if not passed it may dump all the keys.

Also we must rename inspect to avoid conflict with python inspect module.

import inspect

So it is better to rename

from dynaconf.utils import inspect_settings

data = inspect_settings(settings)  # a full dict with all keys included
foo_data = inspect_settings(settings, "foo")  # a full dict with only "foo" history

@rochacbruno what does the "table" format means exactly? Could you provide a snippet of how the following should be rendered?

header:
  filters:
    env: None
    key: foo
    history_ordering: ascending
  active_value: from_environ
history:
- loader: yaml
  identifier: /tmp/pytest-of-pedro-psb/pytest-84/test_inspect_print_key0/a.yaml
  env: default
  merged: false
  value:
    FOO: from_yaml

Hey @pedro-psb it is just a printed output that can be read in the terminal, in future we can use rich.Table but for now it is enough to just print data, so I think you can just by default output the YAML format directly to the stdout.

On list subcommand we are not doing any special treatment on secrets, that is understood that the person running this CLI has full access to the settings environment so we can output secrets or maybe if possible add an option like --hide-secrets to replace with *****

I am not sure it is easy to detect if a variable is a secret, maybe we can by detecting the source being .secrets. or vault.

I guess it would be good to star them out, as someone may want to share this report or something. Not very likely, but this should be easy to do by tracking .secrets or vault loader source.

Does not work with a custom loader

dynaconf on  feature/inspect [$] via 🐍 v3.8.13 (.venv) 
❯ cd tests_functional/custom_loader

dynaconf/tests_functional/custom_loader on  feature/inspect [$] via 🐍 v3.8.13 (.venv) 
❯ cat settings.sff                 
# Stupid File Format
KEYS:name;email;message
VALUES:Bruno Rocha;bruno@rocha.com;Dont use this sff format!

dynaconf/tests_functional/custom_loader on  feature/inspect [$] via 🐍 v3.8.13 (.venv) 
❯ dynaconf -i app.settings list -k NAME   
Working in development environment 
NAME<str> 'Bruno Rocha'

dynaconf/tests_functional/custom_loader on  feature/inspect [$] via 🐍 v3.8.13 (.venv) 621ms 
❯ dynaconf -i app.settings inspect -k NAME
The requested key was not found: 'NAME'

Does not work with a custom loader

@rochacbruno I've cheked the example at tests_functional/custom_loader/ and the custom loader doesn't use BaseLoader, so it would have to copy how BaseLoader implements history recording (creating a SourceMetadata and passing to the obj set or update method).

# tests_functional/custom_loader/my_custom_loader/sff_loader.py:load
+ source_metadata = SourceMetadata('sff', found_file, env)

if key:
    value = data.get(key.lower())  # sff format have lower case keys
+    obj.set(key, value, loader_identifier=source_metadata)
-    obj.set(key, value)
else:
+    obj.update(data, loader_identifier=source_metadata)
-    obj.update(data)

We could:

• Update the example in the docs and in the test to support history.
• Create a custom loader functional_test using BaseLoader (which should work, as builtins use it) and present it as the preferred way in the docs as well.

What do you think?

I think we need to update the docs and test to support history, there are projects out there using custom loaders based on the docs example, so we can point people on how to adjust their loaders to save history.