dynaconf-dev meetings

# Dynaconf-Dev Meeting - Open PRs: https://github.com/dynaconf/dynaconf/pulls - Next Release: - 3.2.11 (may or may not be required before 3.3.0) - 3.3.0 - Early May ? - https://github.com/dynaconf/dynaconf/milestone/23 ## 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 ### 31 October - Planning: - Let's try to release 3.3.0 next week - 3.2.x branch is freezed - let's have a more 3.y releases to refactor the codebase - Goal for 3.4 - Re-write the loading system so it's only responsability is get raw data - It should accumulate the data similar to a ChainMap - Merging the data into Settings must be separate concern - Improve e2e testing - It would be nice to be able to easily test Galaxy or Pulp with dynaconf main AI: - [bruno]: add a workflow that can be trigger manually that tests dynaconf in galaxy - [pedro]: finish performance PRs - [pedro]: release 3.3.0 ### 17 October - 3.2.12 released - PR fix django static url fix https://github.com/dynaconf/dynaconf/pull/1328 - PR to review https://github.com/dynaconf/dynaconf/pull/1229 (disable uppercase force) ### 03 October - [pedro] updates on box replacement - https://github.com/dynaconf/dynaconf/pull/1325 - finally was able to start working on it again. Making progress, not much else to say - [pedro] dynaconf in pulp - pulp_ansible depends on pulp_file, but its possible to disable pulp_file with a setting - starting pulp with ansible and missing pulp_file would raise cryptic errors - used hooks on ansible to validate pulp_file is present, as it's an 'after-merge' value - [pedro] anyone playing with uv? - https://github.com/dynaconf/dynaconf/issues/1276 - that would be nice - [pedro] make release 3.2.x - https://github.com/dynaconf/dynaconf/commits/stream_3.2.6/ - [pedro] dunder merge review (for the 3.3.0): - agreement: default to two dunders, instead of three (I think we've agreed on that? not sure) - agreement: release on 3.3.0 - strange behavior. what to do? - It's buggy / surprising when the index is out of range or the list doesnt exist before. - For the case of updating an existing list it's fine, i guess - We could define it's tech preview, let bug reports rain and fix/un-preview for 3.4 (if that's a thing!) - We could test it with django app cases to know what would be 'expected' (potential popular usecase) - We could make an extensive combinatorics matrix and define behavior for every case. I expect something between 8 and 16 cases. - example of strange behvaior in cases where the list didnt exist before: ```python In [22]: settings.set("f__li___2", "x") In [23]: settings.f Out[23]: <Box: {'li': [[], [], 'x']}> # what? In [24]: settings.set("f__li___2___0", "a") In [25]: settings.f Out[25]: <Box: {'li': [['a'], ['a'], ['a']]}> # this one *might* actually be ok... Assume items of a list follow a similar schema In [28]: settings.set("g__li___0__name", "a") In [29]: settings.g Out[29]: <Box: {'li': [{'name': 'a'}, {'name': 'a'}, {'name': 'a'}]}> # but: In [30]: settings.set("g__li___2__name", "Y") In [31]: settings.g Out[31]: <Box: {'li': [{'name': 'Y'}, {'name': 'Y'}, {'name': 'Y'}]}> ``` ### 08 August **Attendes**: Bruno, Fabricio, Pedro - AAP has some requirements that may get into dynaconf - distributed settings service - distributed sqlite - schema definition with types - Issues - Django fix_absolute_urls and STATIC_URL script prefix - https://github.com/dynaconf/dynaconf/issues/1307 - Dynaconf silently ignore import error due to cyclic dependencies - https://github.com/dynaconf/dynaconf/issues/1308 ### 11 July **Attendes**: Bruno, Fabricio, Pedro - Discussed work for replacing Box: - https://issues.redhat.com/browse/PULP-633 - Let's release that in 3.3.0 - Box methods will be added for compat (e.g, to_yaml, from_yaml) - will contain deprecation warnings - will be removed in v4 - New model makes a clear distinction between internal node state and shared dynaconf state - Idea for replacing the `class Settings` with `class Something(DataDict)` - would improve all the getting intercepation maze - may not be backwards compatible - let's not commit in doing so for 3.3.0 - Future improvements: - loading: have staging area for loaded data, instead of merging directly - merging: refactor and simplify merge code - Some other features needs to get into 3.3.0 - e.g, docs generation from cli from settings.py or schema - not much capactity for working on these right now ### 16 May - Release: 3.3.0 https://github.com/dynaconf/dynaconf/milestone/23 - Validators - Aggregate/consolidate list of validators - Useful for scenario of plugins ```python # Get this validators=[ Validators("a", <conditions-0>, default="X"), ... Validators("a", <conditions-n>, default="Y"), ] # And transform into result = Validators("a", <condition-0 + ... + condition-n, default="Y") ``` ### 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 - https://github.com/dynaconf/dynaconf/issues/1272 - idea of a 'convert script' to collect settings.py which have docstring as comments and yield Validators with that docstring data - docs and AI: - Think about creating a llmstxt for dynaconf - https://llmstxt.org/ - https://repomix.com/ - Dynaconf-Django integration - AAP reference with dynaconf helpers - https://github.com/ansible/django-ansible-base/blob/devel/ansible_base/lib/dynamic_config/dynaconf_helpers.py ### 21 mar - 3.3.0 discussions ### 07 Fev - Reviewed remaining issues for upcoming 3.2.8 release - Design for `list|inspect` using patterns - https://github.com/dynaconf/dynaconf/issues/1218 - Bugs requiring in-depth investigation - https://github.com/dynaconf/dynaconf/issues/1035 - https://github.com/dynaconf/dynaconf/issues/1188 - Other discussion - New ideas on read-only implementation: - https://github.com/dynaconf/dynaconf/issues/1219 - Found bug on cli `list -k` that doesnt find key - https://github.com/dynaconf/dynaconf/issues/1235 --- ## 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 - django issues: - https://github.com/dynaconf/dynaconf/issues/1037 - Django 5.0 https://github.com/dynaconf/dynaconf/issues/1103 - our requirements.txt does not ping django, so we are already testing version 5 - we should add tests to LTS (4.2) - remove support for python 3.8 - end of life in 4 months - https://endoflife.date/python - support for schema - https://github.com/dynaconf/dynaconf/issues/1082 - https://github.com/dynaconf/dynaconf/issues/1045 - what strategy should we use to implement that? - Use the Schema data to configure Dynaconf Validators (don't create another validating mechanism) - Levarage typing.Annotated - check if using `cast` from a builder workrs for autocomplete. Yes, it does! - check if Annotaded works well with autocomplete. Yes, it does! - Only allow keys defined in Schema: - some project may want that features: - https://github.com/ansible/eda-server/blob/main/src/aap_eda/settings/default.py#L107 - for plugable systems (like Pulp), we'd have to merge plugin-defined schemas, or something like that. - New Feature Issue: https://github.com/dynaconf/dynaconf/issues/1104 ### 17/05 - pulp default_storage issue: https://github.com/dynaconf/dynaconf/issues/1097 - PR vault intergration review: https://github.com/dynaconf/dynaconf/pull/1094 - codecov issue, possibly we need to bump the action: https://github.com/dynaconf/dynaconf/actions/runs/9129549267/job/25108597783#step:9:34 - actions: - try to fix default_storages and release 3.3.0 afterwards - add this meeting notes to docs ### 22/03 - Discussion about Schema Validation and Type Hint - new proposal issue: https://github.com/dynaconf/dynaconf/issues/1045 - existing PR: https://github.com/dynaconf/dynaconf/pull/677 - See tradeoff discussed below - (pos meeting note): type hint and schema validation may be trated separetly - 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

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.