2077900b4e
So far, repository paths for local includes were derived from the path name of the config file containing the include, rather than using the actual repository root as specified in the documentation. No one complained so far, some layers simply adjusted their includes to this inconsistency which was only discovered during refactorings. Fix this issue by passing also the repository path along with the config filename down the recursive _internal_include_handler calls. The top-level repo path now needs to be retrieved before the creation of IncludeHandler and passed to it then. This has the side effect of enabling deviating top-level repo paths, a feature that will be used by the upcoming changes for a .config.yaml file in KAS_WORK_DIR. As there are existing users of the old behavior out there, fall back to it if a local include cannot be found under the correct path and warn if this succeeds. This allows smooth migration of layers to the right pattern as they update their kas version. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> |
||
|---|---|---|
| .. | ||
| plugins | ||
| __init__.py | ||
| __main__.py | ||
| __version__.py | ||
| config.py | ||
| configschema.py | ||
| context.py | ||
| includehandler.py | ||
| kas.py | ||
| libcmds.py | ||
| libkas.py | ||
| repos.py | ||