Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Integration of Highlevel API and libopts #2383
The highlevel API doesn't expose its internal
That means we either need to integrate
The global plugin seems like the better way, but it has some problems:
Especially the last point is a huge problem. The only guaranteed solution would be, if we had a way to only enable the plugin, if the application requests it before calling
Yes, I agree that the global plugin is the most beautiful solution. We should implement that but not for the next release.
This is not the first implementation which has
Of course it would be good to have a Windows agent so that we get confirmation, that the Windows specific code is actually working.
Actually, we could also allow
I don't think this problem has something to do with the kdb tool: the kdb tool does not have an env/opt specification. And if it would have, why should it differ from any other application? And even if there are problems, we can easily fix the
But yes: if users pass too general parentKeys (like / or /sw) it is very likely that specifications are conflicting.
But there are solutions to this problem if we mark the top-level keys of the respective specifications. Then we could either:
The test cases are quite easy to write, yes. But because we rely on getting argv from the OS, we need to run the test in a separate process. Additionally local testing is hard, because you can only test the version used for your OS.
I didn't mean to suggest the plugin is impossible, just that we shouldn't expect to be easy to implement.
No kdb was just an example for an application that would likely access very general keys (e.g. spec/).
Even if we find just one specification, it might still be for a different application. i.e.
argv is not very reliable.
Yes, we need a way for an application to tell
Yes, but high-level integration tests are very useful in any case. We do not have enough of those.
Do we really need to achieve this?
Suppose we have two specifications for color:
[sw/myapp1/something] opt/long = color [sw/myapp2/something] opt/long = color
When the executable is called with
For the kdb tool we might want to drop all proc/ keys after the configuration phase, so that configuration of kdb itself and the configuration to be manipulated does not get mixed up. For every other application it does not matter if some proc/ keys are added (which are never looked up anyway).
I thought of a solution:
Key * parentKey = keyNew("/sw/org/myapp/#0/current"); KDB * kdb = kdbOpen(parentKey); elektraSetApplication(kdb, keyName(parentKey)); KeySet * ks = ksNew(0, KS_END); kdbGet(kdb, ks, parentKey); // ...
In this solution an application is identified by the (cascading) parent key of its configuration/specification (which should be unique anyway). An additional benefit would be that other plugins could use this information too, if the need ever arises.
Yes, we do. Your example is an invalid specification and will result in an
As I explained in the documentation of libopts, if we were to allow multiple specifications of the same option, we would need a lot of additional validation to ensure the specifications are compatible.
Lets take the following specification.
[sw/myapp1/something] opt/long = color opt/arg = none [sw/myapp2/something] opt/long = color opt/arg = required
Now suppose we call
Not if we want to use
Your solution works and is architectural sound. Some additional thoughts:
Thank you for the example. Can this also happen for environment variables?
Of course we want to use elektraGetOpts for all Elektra tools.
But why not using the parentKey and disable the cmd-line functionality if the parentKey does not seem to be an application? Only because of the one counter-example where someone accesses the application root itself
As you know we want to change
The real question is actually if we want to force applications to use the
We could still implement the plugin, so that it uses the value from
Currently the only way environment variables can be configured is via the key name. If it ends with
It adds one line, if the application whats to use the global plugin for libopts. Alternatively a direct call to
Yes that would also be possible. Although I would go for a more general solution. IMO in this case we should allow application developers to tell Elektra which global plugins are required, and which are prohibited before calling
That is exactly why
The question is how would you detect that?
I think these keys are quite long. The
Also once shell completion works correctly for all commands, long key names together with
Then the plugin would still not know if it should use cmd-line parsing?
Yes, I am afraid there is no good (*) way around #868. Sometimes applications need to tell what they expect from KDB. And this is the case for cmd-line options. But for cmd-line options we should consider a different default, if said nothing, the cmd-line options should be available.
(*) a workaround would be that applications reset their argv and environ, then the opts plugin could omit to do anything.
If the parentKey matches
We could add
Also: Should the plugin actually be global plugin? Couldn't it just be mounted via spec-mount?
Yes, of course, but there is no need to call the libopts plugin for every interaction with KDB. Most kdbGet calls won't even access any command line specifications.
Is there already a way to do that or would that just be a different kind of use of kdbEnsure?