Elektra
0.8.14
|
Configuration will be in arrays below the keys:
system/elektra/globalplugins/ prerollback postrollback preget postget preset setstorage precommit postcommit
Plugins state in contract that they will work as global plugin, i.e. do not need to work on individual config files, when following contract is present:
infos/global
The kdb
-tool should have following list-like interface:
kdb global-plugin-add kdb global-plugin-del kdb global-plugin-list
Some nice features that will be implemented as global plugins.
Transformation keys which are read and transformed to be usable by the application:
[dir/a] transform=/x transform/python=...upper() /lua=..
(actually two plugins are involved: one that fetches transformation keys, the other that executes the transformation code)
simplifies threading and process locking by not having to think about recursive cases.
Run shell code at end of all plugins, e.g. especially doing
git add git commit
The globbing would be more natural (derived from specification). Or even more advanced ways to copy information from specification to the keys, e.g. type inference
It should be possible to write plugins which need all file names of all resolver plugins. E.g. journalling, global mmap.
Its useful to have some important global plugins, e.g. locking by default. Internal list to be used when no system/elektra/global_mountpoints/ exists.
State diagrams of plugins need to be redrawn to also include global plugin states.
Plugin *globalPlugins [NR_OF_PLUGINS]
to _KDB
kdbOpen
, system/elektra/globalplugins/
is read and plugins are constructed and placed into globalPlugins
.list
plugins, and their subplugins are executed, when system/elektra/globalplugins/_
states they should be executedlock
plugin that executes at begin and end of kdbGet and kdbSet, respective, i.e. postrollback preget postget preset postcommitlock
plugin contains the code currently found in resolvera plugin](http://libelektra.org/blob/master/src/plugins/lua/). In a similar way, someone can write scripts, which are executed on every access to the http://libelektra.org/blob/master/doc/help/elektra-glossary.md "key database".
To mount a lua based filter, you can use:
kdb mount file.ini /lua ini lua script=/path/to/lua/lua_filter.lua
Even though it works well, it is classified as technical preview.
Thanks to Manuel Mausz for this plugin!
In this technical preview, Peter Nirschl demonstrates how a plugin can encrypt Elektra's values. In testcases it is already able to do so, but for the end user an easy way for key derivation is missing.
A big thanks to Peter Nirschl!
Brings if
inside Elektra. It lets you check if some keys have the values they should have.
kdb mount conditionals.dump /tmount/conditionals conditionals dump kdb set user/tmount/conditionals/fkey 3.0 kdb set user/tmount/conditionals/hkey hello kdb setmeta user/tmount/conditionals/key check/condition "(hkey == 'hello') ? (fkey == '3.0')" # success kdb setmeta user/tmount/conditionals/key check/condition "(hkey == 'hello') ? (fkey == '5.0')" # fail
The INI plugin got a near rewrite. Now it handles many situations better, has many more options and features, including:
Thanks to Thomas Waser for this work!
Currently, Elektra has some limitations on how many plugins can be added to certain http://libelektra.org/blob/master/doc/help/elektra-plugins-ordering.md "placements". Because of the rapidly growing number of plugins, some combinations are not possible anymore.
This plugin tackles the issue, by delegating the work to an arbitrary number of subplugins. As a bonus, it works lazily and thus might avoid the loading of some plugins all together.
Thanks to Thomas Waser for this plugin!
You can now mount csv-files. To mount test.csv
simply use:
kdb mount test.csv /csv csvstorage
There are many options, e.g. changing the delimiter, use header for the key names or predefine how the columns should be named. For details see the documentation.
Thanks to Thomas Waser!
The also new plugin lineendings is already superseded by the filecheck plugin.
Thanks to Thomas Waser!
The Enum plugin checks string values of Keys by comparing it against a list of valid values.
Thanks to Thomas Waser!
We are proud that Machinekit starts using Elektra.
Alexander Rössler is digging into all details, and already enhanced the DBUS Plugin for their needs. DBus now can emit a message for every changed key.
A big thanks to Alexander Rössler!
kdb rm system/elektra/version
)kdb set
avoids fetching unnecessary namespacesYou 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-Docu 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 elekt. ra@m arkus -raa b.org
For more information, see http://libelektra.org
Best regards, Markus
Again we managed to release with many new features, many fixes and also other improvements.
getenv(3) is one of the most popular ways to retrieve configuration, even though it has many known problems:
With elektrify-getenv we wrote a solution which solves most of the problems. We use the LD_PRELOAD technique to additionally retrieve values from Elektra, and not only the environment.
You simply can do:
```bash kdb set user/env/override/HTTP_PROXY "http://my.proxy:8080" ```
This will set the HTTP_PROXY
environment variable to http://my.proxy:8080
. Configuration can be retrieved with kdb get
:
```bash kdb get user/env/override/HTTP_PROXY lynx # or start another www-browser with the newly set HTTP_PROXY ```
Or using the man pages:
kdb elektrify-getenv man man --elektra:MANWIDTH=40
Will use MANWIDTH 40 for this invocation of man man. This feature is handy, if an option is only available by environment, but not by command-line arguments, because sometimes environment variables are not trivial to set (e.g. in Makefiles).
Some more examples:
kdb set user/env/override/MANOPT -- "--regex -LC" kdb elektrify-getenv getenv MANOPT # to check if it is set as expected kdb getenv MANOPT # if /etc/ld.so.preload is active
So is this the final solution for configuration and manual elektrification of applications is not needed anymore?
The answer is: no and yes.
It is quite satisfactory for configuration that is inherently sharable (not different from one application to another) and needs the environment semantics, i.e. some subprocesses should have different configuration than others, e.g. in a specific terminal.
But it might not be a good solution for your own application, because libgetenv(3) implies many architectural decision, that other elektrified applications would decide differently, e.g.:
char*
and has no support for other data typesFor more information see http://git.libelektra.org/blob/master/src/libgetenv/README.md "src/libgetenv/README.md"
As always, the API and API is fully forward-compatible, i.e. programs compiled against an older 0.8 versions of Elektra will continue to work.
Because keyUnescapedName
and keyGetUnescapedNameSize
is added in this release, it is not backward-compatible, i.e. programs compiled against 0.8.13, might not work with older 0.8 libraries.
The function keyUnescapedName
provides access to an unescaped name, i.e. one where /
and \\
are literal symbols and do not have any special meaning. NULL
characters are used as path separators. This function makes it trivial and efficient to iterate over all path names, as already exploited in all bindings:
Other small changes/additions in bindings:
Doxygen 1.8.8 is preferred and the configfile was updated to this version.
The symbols of nickel (for the ni plugin) do not longer leak from the Elektra library. As such, old versions of testmod_ni won't work with Elektra 0.8.13. A version-script is now in use to only export following symbols:
In this release, ENABLE_CXX11 was changed to ON
by default.
Note that in the next release 0.8.14 there will be two changes:
By not having to care for pre-C++11 compilers, we hope to attract more developers. The core part is still in C99 so that Elektra can be used on systems where libc++ is not available. Many new plugins are still written in C99, also with the purpose of not depending on C++.
A technical preview of python3 and python2 plugins has been added.
With them its possible to write any plugin with python scripts.
Note, they are a technical preview. They might have severe bugs and the API might change in the future. Nevertheless, it is already possible to, e.g. develop storage plugins with it.
They are not included in ALL
plugins. To use it, you have to specify it:
-PLUGINS="ALL;python;python2"
Thanks to Manuel Mausz for to this work on the plugins and the patience in all the last minute fixes!
The GUI was improved and the most annoying bugs are fixed:
A big thanks to Raffael Pancheri!
The commandline tool kdb
also got some improvements. Most noteworthy is that kdb get -v
now gives a complete trace for every key that was tried. This is very handy if you have a complex specification with many fallback and override links.
It also shows default values and warnings in the case of context-oriented features.
Furthermore:
-v
for setmetaAs Michael Haberler from machinekit pointed out it was certainly not easy for someone to get started with Elektra. With the documentation initiative we are going to change that.
more,thanks | to Pino Toscano |
@
and not \\
.more,thanks | to Pino Toscano |
Any further help is very welcome! This call is especially addressed to beginners in Elektra because they obviously know best which documentation is lacking and what they would need.
kdb-full
and kdb-static
work fine now for Windows 64bit, thanks to Manuel Mausz. The wresolver is now more relaxed with unset environment.
All issues for Mac OS X were resolved. With the exception of elektrify-getenv everything should work now, thanks to Mihael Pranjic:
and thanks to Daniel Bugl:
kdb
worksfurthermore:
__FUNCTION__
to __func__
(C99), thanks to Pino ToscanoThanks to Manuel Mausz for to testing and improving portability!
cmake_parse_arguments
instead of parse_arguments
, thanks to Manuel Mausztype
to command -v
and avoid echo -e
) thanks to Pino ToscanoThere are some misconceptions about Elektra and semi structured data (like XML, JSON). Elektra is a key/value storage, that internally represents everything with key and values. Even though, Elektra can use XML and JSON files elegantly, there are limitations what XML and JSON can represent. XML, e.g., cannot have holes within its structure, while this is obviously easily possible with key/value. And JSON, e.g., cannot have non-array entries within an array. This is a more general issue of that configuration files in general are constrained in what they are able to express. The solution to this problem is validation, i.e. keys that does not fit in the underlying format are rejected. Note there is no issue the other way round: special characteristics of configuration files can always be captured in Elektra's metadata.
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-Docu 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 elekt. ra@m arkus -raa b.org
For more information, see http://libelektra.org
Best regards, Markus
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):
cd ~/projects/abc
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 pwd
/KDB_DB_DIR/filename:
kdb file dir/sw/editor/textwidth
.dir
per defaultdefault.ecf
by defaultWe 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 .dir/default.ecf
.
In the project P we had the following issue: We needed on a specific computer the configuration in /etc to be used in favour 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 favour 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