Flatten options & styles files, use TOML for ORCA options & NWChem styles

[matterhorn103]

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

[matterhorn103]

After these changes:

• The files given by the user-options and highlight-styles keys in pyproject.toml completely describe the userOptions and highlightStyles objects, and exclusively describe them (i.e. their contents equate to the values of the respective key/value pairs in the output of --print-options in the old API)

• The options and styles files may be written in either JSON or TOML

  • As it is a lot nicer to write regex in TOML, the NWChem syntax.json was transcribed to TOML
  • To have at least one example of userOptions specified in TOML, the ORCA options.json was also transcribed to TOML
  • All other options files were left as JSON

• The structure of options and styles files has been partially flattened, thus reducing complexity and improving readability, and in order to make sure the files always describe an object/table overall

  • The UI items in userOptions are no longer listed in an array but are instead specified as key/value pairs, where the keys are the names of the items

  • Tabs in userOptions are also now key/value pairs

  • The new tabbed top-level key in userOptions indicates whether the UI items are grouped into tabs or not

    • If tabbed is false (or simply not specified; false is the default), key/value pairs at the top level are for the UI items (see e.g. dalton/options.json)
    • If tabbed is true, the key/value pairs at the top level are for the tabs; the value of each tab is then an object/table containing the UI items as key/value pairs (see e.g. gaussian/options.json and orca/options.toml

  • The styles in highlightStyles are also now key/value pairs in an object/table rather than items in an array, where the keys are the names of the styles

    • The styles are always at the top level

[ghutchis]

I don't really want to do this right now. I'm handling a lot of moving pieces in the code and you want a significant refactor to the user-options syntax too?

Some of this seems fine, but let's make sure packages install, run correctly, etc. and are tested thoroughly before we tweak this.

I'm okay with allowing user-options to be either JSON or TOML, but please let's not change the syntax of anything in the middle of everything else right now.

[matterhorn103]

I understand completely – believe me when I say I'm not looking to create extra work needlessly 😄

90% of the PR just implements your previous decisions.

The suggested change in syntax was just a proposed solution to the problem that arises from the decisions made: currently, if a tabbed interface is being defined, userOptions is an array of tab objects instead of the usual object/table of UI items, but while the top level of a JSON file can be an array, the top level of a TOML file is always a table. Thus, as it stands, it is not possible to specify a tabbed interface using TOML.

[ghutchis]

I understand - I'm not saying "no" - I'm just saying "hang on for a bit, I'd like to do more testing before I tweak the syntax here"

So I'm good with merging styles as TOML, but I'd like to hold off on "handling tabs in TOML user options" if that's okay.

[matterhorn103]

Sure, that's fine. I'll adapt the PR accordingly. 🙂

[ghutchis]

This looks good - got to fix the lint action sometime to ignore names.