Why aren't parameters saved in JSON files (or similar formats)?

[nbro]

Parameters are specified in text files, which is like the rawest possible file format that you could use to solve this problem. JSON files or similar formats should probably be preferred over plain text files, because they allow a hierarchical/structural representation of the parameters and their values.

[dvpfagan]

Yes, I agree JSON would be more beneficial. Again we are more than happy for this type of improvement to come from the wider community via pull requests. When we get around to doing a new release I'm sure we will use the open issues as a guide for features to add. Thanks Dave

…

On Wed, 30 Dec 2020 at 17:04, nbro ***@***.***> wrote: Parameters are specified in text files, which is like the rawest possible file format that you could use to solve this problem. JSON files or similar formats should probably be preferred over plain text files, because they allow a hierarchical/structural representation of the parameters and their values. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#118>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHTHOWYWRECVLPRUF3ZFITSXNMRNANCNFSM4VOQTJMQ> .

[nbro]

@dvpfagan Ok, what happens if I contribute to this project? Will I be included in the list of contributors and authors, including in the license? You're using GPL, so I guess so (although I don't remember the details). I would like to be acknowledged (i.e. officially be part of the authors/contributors) if I contribute to this project.

[dvpfagan]

@jmmcd thoughts on this? Do we add a contributors section to the readme on the main page? Should we have something in the code explicitly giving credit to people? Should we add @nbro as a member to the project upon a successful pull request?

[nbro]

@dvpfagan I opened an issue specifically targetting the "license & authors" issue: #122, so we may just talk about it there.

[jmmcd]

Changing from plain text to JSON for parameter files would be easy but would not provide any benefit unless we actually took advantage of (eg) the hierarchy. But that would require rethinking and reworking a lot of parameter-handling code. I don't think we should pursue this unless we see a strong example where plain-text can't do the job.

[nbro]

@jmmcd JSON or other file formats may provide more flexibility in the future. I'm not saying that this should be done immediately, but it looks like text files aren't really the right tool for this job. Moreover, it shouldn't be so difficult to change the code. I can do it myself, after someone accepts my latest pull request: #121.

[jmmcd]

As I said, I would need a more convincing case than possible future flexibility. I don't think a PR on this will be accepted.

[nbro]

@jmmcd One advantage of using JSON (or similar formats) is that there are tools that parse JSON and beautify them, so make all files look consistent. With your current setup, it's not possible, unless you write your own beautifier. This is one of the advantages. The other is that configurations' values are really only used for certain parts of package/process, so we could have a hierarchical definition of the configurations, if we wanted. This does not mean we will do this.

[jmmcd]

We really don't need a tool to pretty-print the current colon-separated format.