Nitpick: csv files are not valid csv

[flowstatedev]

First off, thank you very much for doing this! This is a great resource for CIQ devs (all 5 of us).

My nitpicky issue is that the device info csv files are not csv files:

• most applications (e.g. Excel, Numbers) will assume comma as a default delimiter (CSV literally stands for "comma-separated values", although I realize other separators are used. It is unusual, but not unheard of, to see multiple separators in the same file though.
• With the previous point in mind, some reader implementations (such as github) will not like the fact that each record/row does not have the same number of fields/columns
• some applications (such as Numbers) will assume the first line is a header row

e.g. https://github.com/flocsy/garmin-dev-tools/blob/main/csv/device2all-versions.csv

approachs60:2.4.1
approachs62:3.0.12
approachs7042mm:4.2.1,4.2.3,4.2.4,5.0.0
approachs7047mm:4.2.1,4.2.3,4.2.4,5.0.0
...

If this file is opened in Numbers, a table which looks like the following is created (where the first row is incorrectly rendered as a header):

approach60:2.4.1
approachs62:3.0.12
approachs7042mm:4.2.1	4.2.3	4.2.4	5.0.0
approachs7047mm:4.2.1	4.2.3	4.2.4	5.0.0
...

I realize this scheme is partly a consequence of the fact that each record has a variable number of fields. With this in mind, I would invert the current scheme: use a comma to separate the record key (in this case, device id) from the other fields, and use a non-standard separator (such as | or :) to separate the variable-arity fields (in this case, the version numbers.) Or you could stick with a commas, but escape them using quotes.

e.g.

Device ID,Versions
approachs60,"2.4.1"
approachs62,"3.0.12"
approachs7042mm,"4.2.1, 4.2.3, 4.2.4, 5.0.0"
approachs7047mm,"4.2.1, 4.2.3, 4.2.4, 5.0.0"
...

This should result in a nice table which looks like:

Device ID	Versions
approach60	2.4.1
approachs62	3.0.12
approachs7042mm	4.2.1, 4.2.3, 4.2.4, 5.0.0
approachs7047mm	4.2.1, 4.2.3, 4.2.4, 5.0.0
...

If you're on board with this, I'd be happy to a push a PR to implement whichever approach you think is best.

[flowstatedev]

Also, I think if the intent is to create something that's easily machine-readable, JSON would be a good choice (inb4 the device library is already JSON haha.)

[flocsy]

While I agree that there could be different or even better formats, CSV even though originally meant comma separated list, is nowdays used in a broader context. In most decent csv readers (code or app or program) you'll be able to set the separator. Here's how to set it in Numbers: https://apple.stackexchange.com/questions/268051/open-csv-file-with-different-delimiter

[flowstatedev]

I agree that it's not hard to set the separator(s). I appreciate the link, but that wasn't really my point. I was thinking about the default, out-of-the box user experience.

My points still stand:

• Numbers (and other apps) will use comma as a separator by default
• Numbers (and other apps) will interpret the first line as a header by default
• It's somewhat atypical to have multiple separators in a CSV file (regardless of whether the default separator is used or not)
• Regardless of delimiter settings, it's generally recommended that each record/row in a CSV file has the same number of fields/columns (hence the github error message I screenshotted).

The reason I mentioned a different file format is precisely bc CSV isn't really standardized (which is why all of this stuff is up for debate.)

Anyway, it was just a thought. I just figured it would be nice to have an optimal UX out-of-the-box on github and in popular apps like Excel and Numbers. (e.g. Ideally: if the files are viewed in github, github pretty-prints them and makes them searchable. if someone downloads a CSV file and double-clicks it, the file is rendered in a nice way without changing any settings. If I use a VS Code extension like Rainbow CSV, it understands how to display these files.)

Thanks again for the scripts and CSV files!

EDIT: to needlessly revisit this:

A more sensible interpretation than what I had above is that these files have a single separator (:), which means that they have neither multiple separators nor a variable # of columns.

With that in mind, if it were me I'd probably make the following changes:

• change "," to ";" and change ":" to ",". iow, the delimiter between the actual CSV fields becomes "," and the intra-field "delimiter" becomes ";" (to separate multiple values within a single field)
• add a header row

That way the files would be "standard" CSV and have max compatibility out of the box. I realize that the way they are now looks much more natural from a human pov.

But it's no big deal, the files are very useful as-is, and I def appreciate the work you've done!