Describe the bug The docs in https://dynaconf.readthedocs.io/en/latest/guides/testing.html explain how to test with dynaconf. The point is that if you follow the explanation, you will see AttributeError: 'DynaconfDict' object has no attribute 'current_env'

To Reproduce

Just try to follow the steps in https://dynaconf.readthedocs.io/en/latest/guides/testing.html

Expected behavior The code don't fail and the mock can be used.

Debug output

Traceback (most recent call last):
  File "lalala.py", line 5, in <module>
    toml_loader.load(mocked_settings, filename="test_conf.toml", env="testing")
  File "/home/angel/.virtualenvs/navi-Pag0EvBg/lib/python3.6/site-packages/dynaconf/loaders/toml_loader.py", line 38, in load
    loader.load(filename=filename, key=key, silent=silent)
  File "/home/angel/.virtualenvs/navi-Pag0EvBg/lib/python3.6/site-packages/dynaconf/loaders/base.py", line 69, in load
    env_list = build_env_list(self.obj, self.env)
  File "/home/angel/.virtualenvs/navi-Pag0EvBg/lib/python3.6/site-packages/dynaconf/utils/__init__.py", line 220, in build_env_list
    if obj.current_env and obj.current_env not in env_list:
AttributeError: 'DynaconfDict' object has no attribute 'current_env'

Environment (please complete the following information):

• OS: Ubuntu 18.04
• Dynaconf Version 2.2

Hi,

As you are on Dynaconf Issues page I assume you are using Dynaconf, or are interested in using it?

This issue is a placeholder to get feedback from users, can you share your experience?

Or if you are not a user, can you share what are you looking for in a config management library?

Questions

For those using Dynaconf

• Are you using Dynaconf (yes/no)
• Can you share some details? (company, project, stack)
• When did you start using Dynaconf?
• What features you use?
• What features you miss?

For those not using

• If you have tried Dynaconf but decided not to use, can you share why?
• If you are still reading and have not tried yet can you share what you are looking for?

Feel free to share any comment, suggestion you have

Thanks

Let's discuss the breaking changes coming on Dynaconf 3.0.0 https://doodle.com/poll/ke2g4kc6mzwgtavh

There are some issues still opened for 3.0 https://github.com/rochacbruno/dynaconf/milestone/9

The highlights to be discussed are:

• Global settings object is going to be deprecated Users must create their own instance of dynaconf Deprecate

  from dynaconf import settings
  

  New recommended way

   # yourprogram/config.py
   settings = Dynaconf(**options)`
  

  reason Most users are confused about importing direct from dynaconf a singleton config object and when customizations via **options are needed they have to change the whole codebase.

• No more default file paths Right now Dynaconf loads all files named settings.* idea is making it explicit only via option settings_files=[list of paths or globs] e.g:

  from dynaconf import Dynaconf
  settings = Dynaconf(settings_files=["main.toml", "other.toml", "path/*.toml"])
  

  reason Debugging file loading is hard, permissions and other I/O problems may happen idea is to make explicit and raise earlier for errors.

• Envless mode will be default

  Now dynaconf has an envless_mode, which means it can load all variables direct from the main level of a file.

  server = 'bar.com'
  port = 5050
  

  This will be the default and if needed users will provide the list of environments.

  settings = Dynaconf(envs=["development", "production"])
  

  then

  [default]
  server = 'bar.com'
  port = 5050
  [development]
  server = 'dev.com'
  [production]
  server = 'prod.com'
  port = 80
  

• Allow parser to be changed or disabled Right now toml is the only parser for every variable, idea is to make it configurable (and allow users to opt-out) reason Some users reported that wanted raw values instead of parsed by toml.

• dotenv will be disabled by default No more loading of .env unless users explicitly enables it. reason In some environments dotenv is already loaded by the shell tool

• Validators will fire by default if passed to the settings object No need to explicity call settings.validators.validate() if Dynaconf(validators=[...]) is passed it will be called right after the initialization.

• Remove logging completely reason It is easier to debug using pdb/ipdb, logging right now is useless.

• Allow Pydantic BaseModels as validators

dynaconf is properly showing the settings I put into /etc/pulp/settings.py

(pulp) [vagrant@pulp3 pulp]$ dynaconf list -k DATABASES
Django app detected
Working in development environment 
DATABASES: {'default': {'CONN_MAX_AGE': 0,
             'ENGINE': 'django.db.backends.dummy',
             'HOST': 'postgres',
             'NAME': 'pulp',
             'PORT': '5432',
             'USER': 'pulp'}}

However, django is not using the setting. It seems like Django is loading the settings for the database before dynaconf is loaded.

@rochacbruno @jyejare It looks like this has broken integration with environment variables.

If I have dynaconf 3.1.8 installed, and the combination of:

1. settings.yaml field key (nested one level from top map) is present, value is empty
2. validator with default=None for given field key
3. envvar set for nested field key (DYNACONF_something__field_key)
4. settings object configuration that looks like: https://github.com/SatelliteQE/robottelo/blob/master/robottelo/config/init.py#L18

My envvar value is no longer set in the resulting box instance, it takes the validator default of None.

I confirmed its this line in particular by modifying the file in site-packages with 3.1.8 installed.

Originally posted by @mshriver in https://github.com/rochacbruno/dynaconf/pull/729#discussion_r853220515

I can still have:

Dynaconf(merge_enabled=True)

to have everything merged by default. In fact this my main scenarios, because I do not want to add @merge mark with each setting.

But in some cases. Especially with lists I'd like default value to be replaced with a new list. Please, keep @reset mark for such cases. Another option is not to merge lists by default or have two options merge_dict_enabled=True and merge_list_enabled=False (this how I would set them).

Recently python-box broke and also we had to pin python-dotenv, so given the way dynaconf is embedded on libraries and applications looks like a good idea to vendor 3 libs.

• toml
• python-box
• python-dotenv
• click

We use dynaconf to template out a default configuration file in YAML and we've started seeing declarations like these:

default:
  ALLOWED_HOSTS: !!python/object/new:box.BoxList
    listitems:
    - ::1
    - 127.0.0.1
    - localhost
    state:
      box_class: &id001 !!python/name:box.Box ''
      box_options: {}
      box_org_ref: 140462933942512

I realize these are coming from python-box but they weren't present until recently. They don't look mandatory ? A settings file without these seem to work as well.

It unfortunately makes the templated file less readable and definitely not human writable.

For testing in my project i want to add in my conftest.py something like that:

import pytest
import os

@pytest.fixture(scope='session', autouse=True)
def settings():
    os.environ['ENV_FOR_DYNACONF'] = 'testing'

But this is not work ;-(. What can you advise me ? I dont want start my test like that : ENV_FOR_DYNACONF=testing pytest because somebody can miss that command prefix and mess up some dev data.

Describe the bug Migrating from other configuration systems I'd need to configure envvar_prefix to empty string ("") so I can load any environment variable I used before. But it doesn't seem to work with dynaconf.

To Reproduce Steps to reproduce the behavior:

1. Create a basic dynaconf configuration

In config.py:

from dynaconf import Dynaconf

settings = Dynaconf(
    # This is the important line.
    envvar_prefix="",
)

print(settings.FOO)

2. Now create some settings file.

In settings.py:

FOO = 'bar'

3. Finally try running.

export SETTINGS_FILE_FOR_DYNACONF=settings
FOO='ham' python config.py

You will get:

bar

Expected behavior

The print output states:

ham

This means the value from environment variable has overridden the default value from settings.py module

Environment (please complete the following information):

• OS: Ubuntu Linux 20.04
• Python version: 3.8.5
• Dynaconf version: 3.1.2
• Frameworks in use: none.

Additional context Interestingly running in a "hacky" way changes the variable value:

_FOO='ham' python config.py

This is not what I'd expect though. The point is to modify the bare FOO variable.

My project structure:

gfa/ ├── config │   └── settings.yaml ├── init.py ├── main.py ├── resources │   ├── exon_body.bed │   ├── exon_end.bed │   ├── exon_start.bed ├── src │   ├── annotators │   │   ├── get_annots.py │   │   └── init.py │   ├── gfa.py │   ├── preprocess └── tests ├── fixtures │   └── test_bkpt.tsv ├── init.py └── test_get_annots.py

I have a settings.yaml in the config folder with the content below

---
exon_region_dict
  start : '../resources/exon_start.bed'
  stop : '../resources/exon_stop.bed'
  body : '../resources/exon_body.bed'

I call settings.EXON_REGION_DICT in get_annots.py but I get this error line 113, in getattr return getattr(self._wrapped, name) AttributeError: 'Settings' object has no attribute 'EXON_REGION_DICT'

Bug description

dynaconf doesn't define any dependencies (due to vendoring), but that's not really true, because there is one runtime dependency - pkg_resources distributed with setuptools: https://github.com/dynaconf/dynaconf/blob/0439bf836f1a22e96e4c71d388c2e68fd9b70425/dynaconf/contrib/flask_dynaconf.py#L17

How is it possible that it actually works? Only thanks to a "de facto" standard of pre-installing setuptools a) together with Python interpreter b) when creating virtual environments:

venv is available by default in Python 3.3 and later, and installs pip and setuptools into created virtual environments in Python 3.4 and later.

virtualenv needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and pip, setuptools and wheel are always installed into created virtual environments by default (regardless of Python version).

It means setuptools was not explicitly declared, but it was assumed it would be there anyway. But as I mentioned - it never was a real standard and it caused serious issues in the Python build system as precisely described in PEP 518:

But when a project chooses to use setuptools, the use of an executable file like setup.py becomes an issue. You can’t execute a setup.py file without knowing its dependencies, but currently there is no standard way to know what those dependencies are in an automated fashion without executing the setup.py file where that information is stored. It’s a catch-22 of a file not being runnable without knowing its own contents which can’t be known programmatically unless you run the file.

And that's why PEP 518 introduced the build-system table defined in pyproject.toml:

[build-system]
# Minimum requirements for the build system to execute.
requires = ["setuptools", "wheel"]  # PEP 508 specifications.

Thanks to that and PEP 517 - package managers know what are the actual build dependencies and how they should be handled. What does it imply? No need to blindly install setuptools anymore.

Based on that poetry introduced a flag virtualenvs.options.no-setuptools, which is currently disabled by default, but generally recommended:

What's the implication of the above? Well, I guess you already know:

❯ poetry config --local virtualenvs.options.no-setuptools true
❯ poetry add dynaconf
❯ poetry run python -c "from dynaconf.contrib.flask_dynaconf import DynaconfConfig"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/lanskij/Repositories/dyna/.venv/lib/python3.10/site-packages/dynaconf/__init__.py", line 5, in <module>
    from dynaconf.contrib import DjangoDynaconf  # noqa
  File "/Users/lanskij/Repositories/dyna/.venv/lib/python3.10/site-packages/dynaconf/contrib/__init__.py", line 4, in <module>
    from dynaconf.contrib.flask_dynaconf import DynaconfConfig  # noqa
  File "/Users/lanskij/Repositories/dyna/.venv/lib/python3.10/site-packages/dynaconf/contrib/flask_dynaconf.py", line 17, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

Required fixes

• package building

  As showed above - we can't assume anymore setuptools would be for sure pre-installed in given environment. That's why a proper definition of build dependency should be added to pyproject.toml:

  [build-system]
  requires = ["setuptools"]
  build-backend = "setuptools.build_meta"
  

  PS The current usage of setup_requires in setup.py is redundant, it's even mentioned directly in PEP 518:

  Setuptools tried to solve this with a setup_requires argument to its setup() function [3]. This solution has a number of issues, such as:

  • This cannot include setuptools itself nor can it include a replacement to setuptools, which means that projects such as numpy.distutils are largely incapable of utilizing it and projects cannot take advantage of newer setuptools features until their users naturally upgrade the version of setuptools to a newer one.

• package runtime

  Here we have 3 solutions:

  • specify setuptools as a package dependency
  • vendor setuptools
  • get rid of setuptools- and pkg_resources-related runtime logic at all

  Personally - I would vote for the last one. Looking quickly - there's exactly one such line, which is: https://github.com/dynaconf/dynaconf/blob/0439bf836f1a22e96e4c71d388c2e68fd9b70425/dynaconf/contrib/flask_dynaconf.py#L226 That was probably copy-pasted from the flask codebase. But flask maintainers already fixed that on their side in https://github.com/pallets/flask/issues/4419 and switched to the built-in importlib.metadata, so when aligned - there would be also no need for dynaconf to depend on setuptools in runtime anymore.

Describe the bug the reload() function of the LazySettings class does not clear the _loaded_hooks attribute. Because of that, when trying to reload and rerun the loaders, the hook won't run again.

To Reproduce Steps to reproduce the behavior:

Configure a post hook just like in the docs. Create a DynaConf object and then run reload() on the object.

Expected behavior The post hook should run after every reload.

Additional context I'll be glad to make a PR for this myself.

Is your feature request related to a problem? Please describe. Currently, when using a Validator with a custom condition, the error message is not indicative enough.

For example: Validator("ipify_api_list", condition=lambda x: len(x) > 5) would result in: dynaconf.validator.ValidationError: ipify_api_list invalid for <lambda>(['api.ipify.com']) in env main

Describe the solution you'd like Add a new, "error_msg" option for Validator that will be shown as the error message

Additional context I'll be glad to make a PR for this myself.

Discussed in https://github.com/dynaconf/dynaconf/discussions/847

from flask import Flask
from dynaconf import FlaskDynaconf

app = Flask(__name__)
FlaskDynaconf(app, envvar_prefix="PEANUT")

# main.py
# working code

from flask import Flask, render_template, current_app
from dynaconf import FlaskDynaconf

app = Flask(__name__, template_foler=templates")
FlaskDynaconf(app, 
   load_dotenv=True, 
   envvar_prefix_for_dynaconf="DAMNIT"  # 🔴 doc say "envvar_prefix" but that doesn't work 
)

@app.route("/", methods=["GET"])
def index():
    settings = current_app.config
   return render_template("index.html.jinja", settings=settings")

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>

<body>
    <h1>HELP ME!!</h1>
    <div style="border: 1px solid red; width: 100px; height: 100px;">
        {{ settings.APPNAME }}
    </div>
    <div>
        {% if settings %}
            <dl>
            {% for key, value in settings.items() %}
                <dt>{{ key }}</dt>
                <dd>{{ value }}</dd>
            {% endfor %}
            </dl>
        {% endif %}
    </div>
</body>

</html>

FLASK_APPNAME=APP NAME FROM FLASK_APPNAME
DAMNIT_APPNAME=APP NAME FROM DAMNIT_APPNAME

Is your feature request related to a problem? Please describe. Dynaconf offers only one mount point, default is secret. Many enterprises have multiple mount points for departments and different teams and different subpaths for different apps.

Describe the solution you'd like Vault approle itself offers different mount points and allows to read only specific path. Please expose those features of allowing us to specify the mount point and path to CRUD.

Describe alternatives you've considered Skip dynaconf and use vault approles directly

Additional context None

Is your feature request related to a problem? Please describe. vault authentication via approle does not offer skipping of ssl.

Describe the solution you'd like vault_loader.py file, line33 had to be modified by adding verify=False, to skip https verification.

Describe alternatives you've considered None

Additional context Our vault sits in other network with https. Our services however reside adjacent to the vault in the same kubernetes environment. We do not need or want to use https address since it will cause hairpinning of the traffic (traffic goes to nginx ingress, dns, then nginx ingress and then the client of the vault) We directly access vault using the service name of the vault in k8s and even if it is not the case, providing an option to skip https is great. could not find the same in your documentation. https://www.dynaconf.com/secrets/?h=vault#using-vault-server