Dynaconf-Dev Meeting

Action Items

  • Review implementation for dunder list merge and get it ready for release
  • Finish typed dict PR
  • Work on 3.3.0 issues

2025

04 Apr

  • Default on validators
    • AAP wants to keep default on validators, but what they really want is
      • don't have to declare defaults directly on the settings.py
      • declare validators and defaults in a single place
      • basically: a schema-based configuration
    • Coupling defaults with validators can lead to confusing cases
      • when validators are added at after initialization
      • Its ok if the default only get pulled on the get method, but then defaults can't be used as a base for merge operations
      • [pedro] after meeting though:
        • I see two behaviors a user may expect when using defaults:
          • default as initial value: It gets set as the base settings. Enable merges
          • default as fallback value: Its get set if no value is found at a given point in time
        • The 'fallback' behavior may be seen as a merge strategy:
          • Settings A.B gets set if no A.B exists (whenever that's is called, as any other merged)
  • Index dunder
    • [bruno] Review the implementation
    • Decisions:
      • We'll use double underscore as separator
      • A number between two dunders is expected to be an int
      • There's a very small window for breaking users, lets watch
  • docs description
  • docs and AI:
  • Dynaconf-Django integration

21 mar

  • 3.3.0 discussions

07 Fev

2024

09/08

  • Review on DataDict PR:
    • https://github.com/dynaconf/dynaconf/pull/1162
    • DataDict name feels bettere than DictValue
    • Behaviour:
      • Behaves mostly as dict. Lighweight modificaitons on object access and others
      • Represented as Database({a: b, c: d})
      • Transformers: functions that take a raw input and output the DataDict schema type (e.g Plugin(DataDict))
    • Nice internal interface of DataDict.schema with useful things:
      • specs: specification of the schema. Can be used by loaders/dumpers
      • defaults: collected default values
      • validators: validators tree
    • Problem with field: list[Plugin]
      • when field[0] = {"name": 123}, other Plugin defaults won't apply.
      • Solutions: require using Plugin(name=123) to get defaults or create DataList to do that automatically.
    • Should we integrate this with current implementation or leave it separate?
      • Doing it separetly (from scratch) gives more freedom
      • Doing integration we can receive early feedback
  • Dunder index get/set:
    • https://github.com/dynaconf/dynaconf/pull/1001
    • We have a better way of handling this using typed
    • Because of that, it may not make sense to add it now and remove "soon"
    • What should we do?
      • Change ___0 to __0 so it compats with the future change.
        • That will break users that relies on the current behavior
      • Feature-flag this (disabled by default) looks a nice way out.
  • 3.3 release can wait and we can release hotfixes to the 3.2 branch if needed

26/07

  • Discussed some ideas about Box rewrite and internal settings organization
    • Name the nested schema definitions as DataDict
      • it only carries data (no methods)
      • it implements dict dunder methods
    • In settings.object_field.int_field:
      • object_field is really an instance of user-defined class where object_field: UserObject # is a DataDict.
        Avoid magic here
      • int_field is really an int, if that was defined as int_field: int

15/07

  • Review DictValue object/dict access:
    • new implementation is on the way to replace box
    • behaves as a dict. That's very important for programmatic uses (e.g. django/flask plugins)
    • [pedro post comment] dynaconf has human users and machine users (integrations). This was something that became clear to me today, and feels like an important distinction.
  • Alternative names for DictValue:
    • DataDict
    • DictSchema
    • DynaconfSchema
    • Schema
    • [pedro post comment] my priority choice is Schema, DynaconfSchema and DictSchema
  • Key-types and key casing:
    • it would be nice to have a restriction on key types (e.g, only string), but that might not work well with our machine users (integrations with plugins).
    • on load-time we can pre-process keys type and casing. Ideally, on access-time the user should use what's defined in the schema and possibly use alias for alternative access.
  • Remaining issues for 3.3.0
    • 3 issues left
    • AI: write docs for the typed feature

28/06

  • Dynaconf Schema review:
    • https://github.com/dynaconf/dynaconf/pull/1110
    • will extend Validators class to support nested validators on inner fields. Benefits:
      • avoid multiple gets to dynaconf, as only a main dict will have a validator
      • provide better debugging with nested types (list[int])
      • tree validator structure, which might be more easily serializable in the future
    • discussed features for the future:
      • Alias + deprecation, for when a system is changing a variable name
      • ReadOnly and ReadFrom, for better control of loading process
      • Generate schema from runtime settings
  • Dynaconf Roadmap Proposal:
    • >=3.3, <4:
      • work on typed dynaconf improvements
      • work on a parallel re-work of LazySettings, LazySettingsImproved:
        • cleaner interface for user
        • using typed module by default
    • 4.0:
      • add performance tests
      • start using LazySettingsImproved as Dynaconf
      • change Django integration (needs more research):
        • use djangos AppConfig hooks
        • stop overwritting their settings module. Maybe inject a .get for convenience
        • limit actions to startup. No more influence on runtime settings access
      • stop calling set from validators
      • Removals:
        • global pre-instantiated settings: already marked for removal
        • default_settings: use Option class instead
        • vendors: use regular dependencies, when needed
        • box: do our own version of that
    • 5.0:
      • Remove LazySettings interface
  • Next release:
    • we can do 3.3.0 after this feature is complete

14/06

17/05

22/03

  • Discussion about Schema Validation and Type Hint
  • Discussion about validation:
    • cast and default on the validation process was a mistake, because it leads to not easy to predict behaviors.
    • Somethingk to think carefully about for the new project
  • Next release: 3.3.0
    • Review pending issues: Everything is addressed, we just need to merge.
    • Nothing specially important we need to include
Select a repo