Hierarchical Save that respects Scope Order
@jessy-liao is already working on this.
Since Jun 16, 2026.
Assessment
This issue has not been assessed yet.
Description
In save_config(...), we can only enter one scope, so we can't fan out overrides. In some situations, it's desirable to save overrides to only one scope (i.e: computer-specific tuning values).
In other cases, though, it may be necessary to fan out overrides out to multiple scopes in the order that they arrived. This will involve holding onto the scope order used to initially bring down a config with get_config and then passing it back to the save_config such that keys fan out to the locations that they came from.
User Stories
Here are a few use cases to start from:
- For a given namespace, load a hostname and subject-specific config.
- Make alternations to hostname-scope fields. Make hostname-scope. Save changes back to the hostname scope.
- OR Make hostname-scope and subject-scope changes. Save changes back to their respective scopes.
- OR Make hostname-scope and subject-scope changes. Save hostname-scope changes but blow away the subject-scope changes.
- OR make hostname-scope changes. Save all hostname-scope changes back to the default scope.
Extras:
- do extra fields get added to the lowest level scope?
- add a field
Building Blocks
- a deep-update that only updates fields that already exist in the dict being updated.
- a warning for fields that were not saved during the save process.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 4
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from AllenNeuralDynamics/ficus
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
AllenNeuralDynamics/ficus#87 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
AllenNeuralDynamics/ficus#85 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
AllenNeuralDynamics/ficus#84 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
AllenNeuralDynamics/ficus#54 · 4 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
AllenNeuralDynamics/ficus#93 · 2 comments ·
All issues in AllenNeuralDynamics/ficus
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
sierra-research/tau2-bench#635 ·
Maintainers usually reply within 1 day
-
The add-ssm-model skill requires a Cython simulator; the contributing guide allows Python onesPossibly taken @fmuia claimed this today. Opendocumentation skill
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
lnccbrown/ssm-simulators#406 ·
Maintainers usually reply within 4 days
-
Difficulty 1/5 Under an hour Newbie friendliness 95/100
btclib-org/btclib-ecc#309 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
jbacalso24/mimry#459 · 1 comment ·
Maintainers usually reply within 1 day
-
[Bug] POST /revoke with a FastMCP access token is a silent no-op (ownership gate never matches)Openauth bug high-priority
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day