finalize infos/status

[markus2330]

add in CONTRACT.ini

• finish [FLOSS H3] simplify infos/status #4758
• example .. plugin is only an example how plugins should be (doc+template), see Config File Examples #1012
• remove nodep and use dependencies/ instead

also add automatic check

• documentation
• environment

check features of plugins manually

• read
• write
• spec//
• preserves/order
• preserves/comment
• preserves/comment/empty
• preserves/indentation
• limited
• arbitrary/keyset
• arbitrary/metadata
• directory/value
• directory/holes
• type
• array
• format/array
• format/hierarchy
• format/type
• format/human/read
• format/human/write

[markus2330]

Maybe we also can find automated ways here?

[markus2330]

@Namoshek Would nocomments and noorder be useful for the web frontend?

[Namoshek]

Are not (almost) all plugins noorder? I thought during import, when keys are put into a keyset, they get automatically sorted in alphabetical order?

I think they are not really useful/necessary, because on the one hand, the fact that comments are missing is immediatly visible and on the other hand, it should be clear that not all formats do even support comments (e.g. json). So I wouldn't really use this information.

But you brought the idea up to me to just pass all statuses through the REST API to the user. Then additions to the plugin information would only require a change in the frontend in future, not to the API description and the backend anymore.

[markus2330]

Are not (almost) all plugins noorder? I thought during import, when keys are put into a keyset, they get automatically sorted in alphabetical order?

Yes, most plugins are noorder and nocomment. Exceptions are hosts and ini.

not all formats do even support comments (e.g. json)

Yes, that is similar to readonly/writeonly/limited: sometimes only implementation is missing, sometimes it is a wanted limitation.

But you brought the idea up to me to just pass all statuses through the REST API to the user. Then additions to the plugin information would only require a change in the frontend in future, not to the API description and the backend anymore.

Good idea!

[KurtMi]

Should I add those?

[markus2330]

Could you first investigate which of ìnfos/status`(also of those we already have) we can determine automatically easily (within your tool)?

[KurtMi]

I investigated a bit and determined the following tags as automatic checkable.
unittest look for testmod_PLUGIN* preset
nodep check infos/recommends or infos/needs ?
readonly see in code if only elektraPLUGINGet is there (maybe tricky)
writeonly see in code if only elektraPLUGINSet is there (maybe tricky)
nodoc only contract in README.md

Do you think this is possible and right? Are there more?

[markus2330]

Hello, thanks for the investigation!

unittest look for testmod_PLUGIN* preset

Yes, but ADD_TEST or add_plugintest in the CMakeLists.txt should be more robust.

nodep check infos/recommends or infos/needs ?

Seems like the docu was misleading, I updated it. It is actually about presence of LINK_LIBRARIES or find_package or find_library. The tagging should be correct at the moment, so you can easily verify if you missed something.

readonly/writeonly

I do not think that this is possible to detect. Especially in elektraPLUGINGet there is always the returning of the contract.

nodoc only contract in README.md

I think we can be more strict: if it has a length similar to template and no code examples we give it nodoc.

Are there more?

• configurable: if the plugin uses elektraPluginGetConfig
• memleak: if MEMLEAK is present in CMakeLists.txt
• noabi .. plugin depends on some internal information of Elektra (kdbprivate.h)

I updated the top post with this check list.

[KurtMi]

#1069 contains:

• configurable
• memleak
• unittest
• nodep
• nodoc

I have some issues with the nodoc, its hard to say what is an example and what not.

[markus2330]

Thank you, nicely done! Can you please tick it in the above post?

nodoc

Simply count the lines of source within markdown.

Can you also check kdbprivate.h?

[markus2330]

Do you think it is also possible to grep getenv from the source and add all environment variables being used by a plugin? (similar to grepping for kdbprivate.h)

[github-actions]

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 💖

[github-actions]

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 💖