You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.
How would using gopts help with making it work properly?
There is already one reason above (externally accessible spec). Other reasons are:
IIRC elektraGetOpts does not consider meta:/default at all.
elektraGetOpts definitely doesn't handle any other spec like e.g. meta:/type
AFAIK kdb's profile feature can be used to set default arguments within the KDB. That would automatically be handled correctly with gopts, since it would load the proc:/ keys at the right moment for all spec validation to work correctly (at least on new-backend it will) and a cascading lookup would return the correct key for everything.
I think this should be clearly stated in the docu of elektraGetOpts. Otherwise people might use elektraGetOpts "by accident" as they might not know about gopts.
The tutorial for command line options already recommends gopts and only briefly explains how to use elektraGetOpts. It also explains the downsides of doing so. The doxygen comment of elektraGetOpts does not directly mention gopts, but it refers to the tutorial.
What exactly should we improve here? IMO this is again more of a discoverability issue not an issue with actual docs content.
The doxygen comment of elektraGetOpts does not directly mention gopts
This should be changed. It should recommend to use gopts, with the reasons you outlined.
IMO this is again more of a discoverability issue not an issue with actual docs content.
Yes, it is a discoverability issue, thus it should be mentioned in elektraGetOpts. We should also mention it in the dev guide for application developers #4436.
I mark this 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 by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖
There is already one reason above (externally accessible spec). Other reasons are:
elektraGetOpts
does not considermeta:/default
at all.elektraGetOpts
definitely doesn't handle any other spec like e.g.meta:/type
kdb
's profile feature can be used to set default arguments within the KDB. That would automatically be handled correctly withgopts
, since it would load theproc:/
keys at the right moment for all spec validation to work correctly (at least onnew-backend
it will) and a cascading lookup would return the correct key for everything.Originally posted by @kodebach in #4438 (comment)
I think this should be clearly stated in the docu of elektraGetOpts. Otherwise people might use elektraGetOpts "by accident" as they might not know about gopts.
@kodebach can you take this issue?
The text was updated successfully, but these errors were encountered: