create script to update infos/status

[markus2330]

Missing points:

• no docu
• configparser dep

Its easy to check infos/status (e.g. with grep -rH "^- infos/status" */README.md | grep -v nodep), but its not so easy to add tags if you want them inserted in the order given in doc/CONTRACT.ini.

It would be nice to have a script to edit metadata for many plugins, e.g. like it is done in a37581f

[KurtMi]

Can it be the doc/CONTRACT.ini?
Is the order defined by the integer followed by the "tag"?

[infos/status]
type = vector<int enum>
  {"default",      64000}, ; will be added by the build system for KDB_DEFAULT_STORAGE and KDB_DEFAULT_RESOLVER
  {"recommended",  32000}, ; in case of doubt, use this plugin
  {"productive",    8000}, ; actively used in productive environments, not only by maintainer

It is new to me that the "tags" must be in an order and in the commit you mentioned some "tags" are out of order btw.

Should the script do the job for all plugins or should the pluginname be specified?

[markus2330]

Yes, sorry, I mean doc/CONTRACT.ini. Yes, they are out-of-order now, I thought it takes less time to write such a tool than to order it once by hand.

Bascially any consistent order would be okay, I would use it as it is placed in the file (for the case that numbers occur twice).

Synopsis could be something like:

update-infos-status [--tags <list of status>] [<list of plugins>]

Without tags or plugins it would only validate and order all tags of all plugins. So it would be nice if wrong tags are rejected.

In long term, the script should also do some basic checks, e.g. look into the CMakeLists.txt if unit tests or dependencies are present and automatically update the tags accordingly.

It is enough if the script works in-source (so you can assume that the files are located relative to the script). You can also modify doc/CONTRACT.ini if it makes the writing of the script easier.

[KurtMi]

alright

[KurtMi]

Should the tag option add or update the whole status?
Would something like:
update-infos-status [(--add <status>|--del <status>|--set <status>)] [<list of plugins>]
not be nicer?
if no plugins it will it do for all. If no "command" it will validate.

[markus2330]

Yes, my synopsis was only a suggestion, I like your proposal!

Maybe we should go more for fixing/updating, less for validation. So simply remove obsolete tags (which are not in CONTRACT.ini). So instead of "validation error, tag X not present" something like "tag X not present, thus it was removed".

[markus2330]

Any progress here? We have plenty of new infos/status to add ;)

See #666

[markus2330]

Can you add some documentation to it?

The configparser dep also seems to be problematic. I have installed: python-configparser (3.3.0r2-2). Can you use the python binding of Elektra instead?

scripts/update-infos-status
Traceback (most recent call last):
  File "scripts/update-infos-status", line 126, in <module>
    main()
  File "scripts/update-infos-status", line 53, in main
    tags = parseContract ()
  File "scripts/update-infos-status", line 21, in parseContract
    config.read_string("[dummy]"+contract.read())
  File "/usr/lib/python2.7/dist-packages/configparser.py", line 732, in read_string
    sfile = io.StringIO(string)
TypeError: initial_value must be unicode or None, not str

[KurtMi]

Where should I write the documentation?

[markus2330]

Add some information with --help seems to be best. (Thus it only operates within source code we won't install it and thus a man page is not needed).

[markus2330]

Thank you, the parsing is now a bit buggy (if ìnfos/status occurs somewhere else), but it should be enough for an internal tool. Thank you!