The recent refactoring was instrumental to ease the inclusion of other dibs.yml (or whatever configuration file) by means of packs. In particular, the extends keyword is somehow prepared to do this with syntax <name>@<pack>.
It should be designed and implemented.
Design
-
An external/remote file is always addressed as part of a file-based pack
- it might be the indication of a file in a directory-based pack
- complete syntax would be
<name>@<packpath>, where in directory-based packs the packpath would be something like <pack>/<filepath>.
- slashes in the name of a pack are discouraged and in case must be percent-encoded
-
A secondary configuration file is always loaded during the process, after proper resolution and local download of the resources indicated by packpath
-
the secondary configuration file creates a "nested" scope that inherits some data from the calling scope. Values are overridden in the tighter scope.
env, enviles up to the calling point (put in the normal chain of environment providers)
- named variables
The recent refactoring was instrumental to ease the inclusion of other
dibs.yml(or whatever configuration file) by means of packs. In particular, theextendskeyword is somehow prepared to do this with syntax<name>@<pack>.It should be designed and implemented.
Design
An external/remote file is always addressed as part of a file-based
pack<name>@<packpath>, where in directory-based packs the packpath would be something like<pack>/<filepath>.A secondary configuration file is always loaded during the process, after proper resolution and local download of the resources indicated by packpath
the secondary configuration file creates a "nested" scope that inherits some data from the calling scope. Values are overridden in the tighter scope.
env,envilesup to the calling point (put in the normal chain of environment providers)