Again we managed to release with new features, many build system fixes and also other improvements.
This namespace adds per-project or per-directory (hence the name) configurations. E.g. think how Git works: not only /etc and ~ are relevant sources for configuration but also the nearest .git directory.
This technique is, however, much more widely useful than just for git repositories! Nearly every application can benefit from such a per-dir configuration. Its almost certain that you have already run into the problem that different projects have different guidelines (e.g. coding conventions, languages, whitespace requirements, line breaks, ..). Obviously, thats not a per-user configuration and its also not a per-file issue (thats how its usually solved today). So in fact you want, e.g., your editor to have an additional per-project layer to choose between such settings.
The technique is useful for nearly every other tool:
It is simple to use, also for the administrative side. First, change to the folder to your folder (e.g. where a project is):
Then add some user (or system or spec) configuration to have some default.
kdb set user/sw/editor/textwidth 72
Then verify that we get this value back when we do a cascading lookup:
kdb get /sw/editor/textwidth
The default configuration file for the dir-namespace is
kdb file dir/sw/editor/textwidth
We assume, that the project abc has the policy to use textwidth 120, so we change the dir-configuration:
kdb set dir/sw/editor/textwidth 120
Now we will get the value 120 in the folder ~/projects/abc and its subdirectories (!), but everywhere else we still get 72:
kdb get /sw/editor/textwidth
Obviously, that does not only work with kdb, but with every elektrified tool.
For cascading mountpoints, the dir name is also automatically mounted, e.g.:
kdb mount editor.ini /sw/editor ini
But its also possible to only mount for the namespace dir if no cascading mountpoint is present already:
kdb mount app.ini dir/sw/app tcl
In both cases keys below dir/sw/editor would be in the INI file
.dir/editor.ini and not in the file
In the project P we had the following issue: We needed on a specific computer the configuration in /etc to be used in favor of the dir config.
We could easily solve the problem using the specification:
kdb setmeta spec/sw/P/current/org/base override/#0 /sw/P/override/org/base
Hence, we could create system/sw/P/override/org/base which would be in favor of dir/sw/P/current/org/base. So we get system/sw/P/override/org/base when we do:
kdb get /sw/P/current/org/base
Alternatively, one could also use the specification:
kdb setmeta spec/sw/P/current/org/base namespace/#0 user kdb setmeta spec/sw/P/current/org/base namespace/#1 system kdb setmeta spec/sw/P/current/org/base namespace/#2 dir
Which makes dir the namespace with the least priority and system would be preferred. This was less suitable for our purpose, because we needed the override only on one computer. For all other computers we wanted dir to be preferred with only one specification.
The great thing is, that every elektrified application, automatically gets all the mentioned features. Not even a recompilation of the application is necessary.
Especially the specification provides flexibility not present in other configuration systems.
Raffael Pancheri again did a lot of stabilizing work:
The GUI can be handy for many purposes, e.g. we use it already as xml and json editor. Note that there are still some bugs.
ELEKTRA_VERBOSE_BUILDfixed, thanks to Kurt Micheli
ELEKTRA_VERBOSE_BUILD, thanks to Manuel Mausz
BUILD_TESTINGactivated, but not
HTML_TIMESTAMPto make build reproduceable
As always, the API and API is fully compatible. Because nothing was added, its even possible to link against an older version of Elektra (if compiled against 0.8.12).
In plugins some small changes may effect compatibility:
These two points are also the only unit tests that fail when Elektra 0.8.12 is used with 0.8.11 unit tests.
You can download the release from here and now also here on GitHub
This release tarball now is also available signed by me using gpg
already built API documentation can be found here
Subscribe to the RSS feed to always get the release notifications.
For any questions and comments, please contact the Mailing List the issue tracker on GitHub or by mail firstname.lastname@example.org.
Permalink to this NEWS entry
For more information, see https://libelektra.org
Best regards, Markus