Libelektra: Elektra Does Not Load Required Plugins for Default Storage

[sanssecours]

Steps to Reproduce the Problem

1. Clone the repository

   git clone https://github.com/ElektraInitiative/libelektra.git
   

2. Create build directory

   mkdir -p build
   

3. Create the build system using YAML CPP as default storage

   cd build
   cmake -GNinja                      \
        -DKDB_DB_FILE='default.yaml' \
        -DKDB_DB_INIT='elektra.yaml' \
        -DKDB_DEFAULT_STORAGE=yamlcpp
        ..
   

4. Translate Elektra

   ninja
   

5. Run the following commands

   kdb set user/level1 Overworld
   kdb set user/level1/level2 Underground
   kdb get user/level1
   

Expected Result

The last command should print the following output:

Overworld

.

Actual Result

The command prints nothing. The problem here seems to be, that Elektra does not load the required plugins of YAML CPP, namely Base64 and most importantly Directory Value.

If you use dump as default storage plugin, then the following works without problems:

kdb mount config.yaml user yamlcpp
kdb set user/level1 Overworld
kdb set user/level1/level2 Underground
kdb get user/level1
#> Overworld

.

System Information

• Elektra Version: master
• OS: macOS 10.13.3

[markus2330]

Thank you for reporting!

Yes, unfortunately dependencies cannot be considered for default plugins used in the bootstrap phase. This is one of the reason why dini was needed (to pull in dependencies ini needs).

I was thinking about a way to generate plugins such as dini but it might be overkill. We could add some additional filter plugins to be used by default.

What might work for you, is to mount the plugin on / (and spec):

kdb mount default.yaml / yamlcpp
kdb mount default.yaml spec yamlcpp

Then the described problem would only exist within system/elektra.

[markus2330]

A completely different approach would be to implement a bootstrap plugin that reads and enforces the contracts of the to-be-loaded plugins at run-time. This would require to reimplement quite a bit of the mount logic. But then it would work as expected by @sanssecours.

It would not, however, solve the problem @tom-wa once described: He wanted plugin configuration to be encrypted. To fix that, we would need to double-bootstrap a configuration for the bootstrap plugin.

When redesigning the plugin architecture we should address these problem.

[sanssecours]

A completely different approach would be to implement a bootstrap plugin that reads and enforces the contracts of the to-be-loaded plugins at run-time. This would require to reimplement quite a bit of the mount logic. But then it would work as expected by @sanssecours.

That would be really great, and in my opinion an essential step for a component based default storage plugin, based on a human readable configuration format such as YAML.

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart:

[markus2330]

What is described here is post-1.0 as TOML does not have deps we do not need this now.