Hello everyone,
## Python Plugins
A technical preview of [python3]
(http://git.libelektra.org/blob/master/src/plugins/python)
and [python2](http://git.libelektra.org/blob/master/src/plugins/python2)
plugins has been added.
With them its possible to write any plugin, not only applications, with the
python language.
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!
Feedback and Contribution is welcome!
Join us on [github](http://libelektra.org).
# Rest of release notes for Elektra 0.8.13 follows:
For a html site visit:
http://doc.libelektra.org/news/3c00a5f1-c017-4555-92b5-a2cf6e0803e3.html
For general information about Elektra, see [http://libelektra.org]
(http://libelektra.org)
## Elektrify-getenv
getenv(3) is one of the most popular ways to retrieve configuration,
even though it has many known problems:
- no standard way to modify it
- relogin (or restart of shell) necessary
- names are flat (no hierarchical structure)
- cannot be set for individual applications
- different in at, cron and similar scripts
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.:
- it uses global variables (getenv(3) has no handle)
- it uses mutex for multi-threading safety
- the API getenv(3) only returns `char*` and has no support for other data
types
For more information see [src/libgetenv/README.md]
(http://git.libelektra.org/blob/master/src/libgetenv/README.md)
## Compatibility
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:
- [jna (java)]
(http://git.libelektra.org/blob/master/src/bindings/jna/HelloElektra.java)
- [lua]
(http://git.libelektra.org/blob/master/src/bindings/swig/lua/tests/test_key.lua)
- [python2]
(http://git.libelektra.org/blob/master/src/bindings/swig/python2/tests/testpy2_key.py)
- [python3]
(http://git.libelektra.org/blob/master/src/bindings/swig/python3/tests/test_key.py)
Other small changes/additions in bindings:
- fix key constructor, thanks to Manuel Mausz
- add copy and deepcopy in python (+examples,+testcases), thanks to Manuel
Mausz
- dup() in python3 returned wrong type (SWIG wrapper), thanks to Toscano
Pino
for reporting, thanks to Manuel Mausz for fixing it
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 foll
