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:
kdb set user/env/override/HTTP_PROXY "http://my.proxy:8080"
This will set the
HTTP_PROXY environment variable to
Configuration can be retrieved with
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 types
For more information see 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.
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.
keyUnescapedName provides access to an unescaped name, i.e. one where
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:
libelektra*for module loading system
elektra*for proposed and other functions (no ABI/API compatibility here!)
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:
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.
As 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.
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-static work fine now for Windows 64bit, thanks to Manuel Mausz.
The wresolver is now more relaxed with unset environment.
All issues for macOS were resolved. With the exception of elektrify-getenv everything should work now, thanks to Mihael Pranjic:
and thanks to Daniel Bugl:
__func__(C99), thanks to Pino Toscano
Thanks to Manuel Mausz for to testing and improving portability!
parse_arguments, thanks to Manuel Mausz
command -vand avoid
echo -e) thanks to Pino Toscano
There 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 firstname.lastname@example.org.
Permalink to this NEWS entry
For more information, see https://libelektra.org
Best regards, Markus