type plugin not mounted

[markus2330]

Steps to Reproduce the Problem

Do as instructed in examples/highlevel:

cd examples/highlevel
sudo kdb mount spec.ini 'spec/sw/example/highlevel/#0/current' ni
sudo kdb import 'spec/sw/example/highlevel/#0/current' ni < spec.ini
sudo kdb spec-mount '/sw/example/highlevel/#0/current'

and then try to set an invalid value:

kdb set /sw/example/highlevel/#0/current/myint abc

Expected Result

That it fails with an type error.

Actual Result

It succeeds.

System Information

• Elektra Version: master

Further Log Files and Output

It seems like the type plugin is not mounted and #2377 did not improve the situation:

kdb mountpoint-info /sw/example/highlevel/#0/current
Version: 0.8.25
Default resolver: resolver_fm_hpu_b
Default storage: dump
Mountpoint: /sw/example/highlevel/#0/current
File: highlevelexamples.conf
        config:
        fcrypt/textmode = 0
        path = highlevelexamples.conf
getplugins:
        #0#resolver
        #5#dump#storage#
        #9#hexnumber#hexnumber#
setplugins:
        #0#resolver
        #1#hexnumber
        #5#storage
        #6#sync#sync#
        #7#resolver
errorplugins:
        #5#resolver_fm_hpu_b#resolver#

[kodebach]

I observed the same behaviour. Weirdly the hexnumber plugin is mounted instead although none of its metadata is used.

[markus2330]

Yes, it is weird but understandable: the hexnumber plugin also provides "type" as meta data. It is preferred because it has a better score in info/status.

So we either:

• improve the type plugin to have the better score
• remove the "type" specifier in hexnumber
• improve the spec-mount tools to understand the meta-value of type.
• finish the type dispatcher #1373 (which would be the only plugin to take care of type and dispatches the information to other plugins)

[kodebach]

Shouldn't we just mount all plugins that use a certain metadata? If certain plugins would conflict with each other, we should have a way to state that in the infos of those plugins. Only in conflicting cases the plugin with the better score should be chosen.

• improve the type plugin to have the better score
• remove the "type" specifier in hexnumber

One of these would be the quick solution. Type dispatcher seems like a good idea, but would probably take some time. If we want to elektrify LCDproc without C++ dependencies, we need to rewrite the type plugin anyways, so I guess improving the type would be the best way to go for now.

[markus2330]

Shouldn't we just mount all plugins that use a certain metadata?

No, a plugin providing metadata means that the plugin fulfills this property. Otherwise non-idempotent actions like renaming would not work.

If certain plugins would conflict with each other, we should have a way to state that in the infos of those plugins.

This is quite problematic because then you need an NP-complete solver to find the correct plugins. It is also quite error-prone to specify all conflicts correctly. (and assumes a closed world)

If we want to elektrify LCDproc without C++ dependencies, we need to rewrite the type plugin anyways, so I guess improving the type would be the best way to go for now.

Yes, a type plugin written in C that checks for the basic types and calls other validation plugins if type is not supported (like hexcode) should be viable. Most of the complexity in #1373 is not needed for LCDproc. But let us see what @Piankero says. Validation is low-priority work for you (only if everything else already works.)

[kodebach]

a plugin providing metadata means that the plugin fulfills this property

Well in that case hexnumber doesn't provide type... We should also make the documentation of CONTRACT.ini more specific, so that developers know this is what happens when you add metadata to your infos/metadata.

[markus2330]

A wrote a bit about spec-mount and specifications in 7d6b724

Well in that case hexnumber doesn't provide type

I fixed it in df3409c