Are params CSVs autogenerated or used anywhere apart from user docs?

[shnizzedy]

As far as I can tell, the CSV docs/_sources/_static/params are only used to generate tables like but I don't think they're autogenerated or used to populate that information anywhere else.

Since those descriptions and potential values either are (or should be) reused between the docs, the GUI, and potentially in places like the YAML comments, helpstrings, docstrings, and C-PAC errror and warning messages, it would be good to single-source-of-truth (SSOT) that information.

Now that configs are nested, I think CSVs aren't the best choice for storing that information.

1. tables with complex merged cell format in Key column

We could do tables like (and do them programmatically once we have a SSOT set up for this information), but until we have it set up to be handled programmatically, it'll be tedious to update everything to this format.

The main advantage I see to this format is the clarity of where / how / how deep any given key is nested.

Other ideas:

2. direct users to the comments in the default pipeline until we have the SSOT set up

fcp-indi.github.com/docs/{version}/user/pipelines/default will include that version's default pipeline with YAML-syntax highlighting.

3. keep the CSV-friendly table format and use JSON-style keys

With keys written like pipeline_setup.system_config.on_grid.run in the Key column

---

Other ideas? Thoughts for now? For the short-, medium-, and long-term?

[sgiavasis]

For the short/medium term, let's go with #2 for sure. I've been playing with the idea of somehow making the pipeline config itself as the SSOT in some way.

If the comments in the default pipeline say it, that's what it should say everywhere etc.

[shnizzedy]

#248 replaces the params tables with excerpts from the default pipeline. We will have to update the line numbers in this repo when things in the default pipeline move.