Functions to automatically generate reader table for documentation #2108
Conversation
| file format. This can be multiline if formatted properly in YAML (see | ||
| example below). | ||
| status | ||
| The status of the reader (e.g. Nominal, Beta, etc.) |
There was a problem hiding this comment.
Should we be clear about what options should be used here? Maybe limit it to a set of 3 or 4?
- Nominal
- Beta
- Alpha
Not sure we need something more than those. Other ideas?
There was a problem hiding this comment.
Will add Alpha. But in the old table there sometimes are comments for status other than the suggested three (for example the seviri_l1b_nc reader says that HRV is currently not supported. I don't know if such comments should be in a different column or should be allowed in the status column?
There was a problem hiding this comment.
...yeah that's difficult to say what is best. It makes the most sense in status, but it also seems ugly and prevents that column from staying small.
There was a problem hiding this comment.
@djhoese so I kept the comments in the status column for now since only a few of the readers had status comments and it felt overkill to have a extra column which is mostly empty. It looks like this now:
I added questionmarks for readers for which the status was unclear for me (see my comment below)
|
I updated all the reader config files. Additionally I added https://datatables.net java script which makes the reader table search- and sortable (or any table for that matter if Apart from that there are a couple of readers which were not present in the "old" table so I did not know the status of these:
|
|
@djhoese @pnuu @sfinkens I added the status information for the readers in question based on the slack discussion. So in addition to alpha, beta and nominal there is now defunct. I was thinking that maybe it would be good to "explain" each status above or below the reader table so users which might not be so familiar with these terms know what to expect. At least for the defunct status I think it would be good to add a little footnote. Next to the explanation what it means, this opens up the opportunity to encourage users to work on them and make a PR. |
|
@BENR0 Thanks. That sounds like a good idea. |
|
@djhoese I added some hints regarding the status below the table. Please have a look at it to see if this agrees with how you guys think about the different status meanings. |
|
@BENR0 could you merge current pytroll main with your branch? It looks like your fork's main branch is very old and even has appveyor configuration files in it which we haven't used for a long time. |
Co-authored-by: David Hoese <david.hoese@ssec.wisc.edu>
djhoese
added
documentation
component:readers
cleanup
|
@BENR0 once the merge conflicts are fixed, is this PR ready for full review and merge? |
|
Yes I would think so if there are no other suggestions. |
Codecov Report
@@ Coverage Diff @@
## main #2108 +/- ##
=======================================
Coverage 93.88% 93.88%
=======================================
Files 283 283
Lines 43093 43093
=======================================
Hits 40458 40458
Misses 2635 2635
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
BENR0
requested review from
adybbroe,
mraspaud,
sfinkens,
pnuu and
gerritholl
as code owners
|
@mraspaud while using the table this morning I found some typos. Nothing serious but should I fix them and push again? |
|
@BENR0 sure, just make a PR, it should be merged quickly :) |
This is a first draft for a feature mentioned in #2096 to automatically generate the reader table in the documentation from the reader yaml config files.
This adds new key words to the reader yaml file (i.e. status and supports_fsspec).
Currently I have added these key words to all the readers which already support fsspec for demonstration purposes. I would add the relevant keywords to all readers yaml files when this draft gets positive feedback.
Other todos are to integrate this into the documentation building process maybe by customizing the makefile to run a python script which writes the table to a rst file which then can be included in the documentation.