BoM File format

[hoijui]

Should/do we specify the BoM files format somewhere? If not, its usefulness becomes quite low, as one does not know how to parse it and make use of it, without human interaction for each project in each place where it gets parsed.

[moedn]

I remember some relevant discussions about this somewhere in these issues :)

short: we couldn't find a way how to control neither the BoM structure nor it's file format. While for simple projects it is possible to share a CSV, complexer projects may require on-demand created or even interactive BoM's (such as LibreSolars MTTP or OpenFlexure). Or even simpler projects may just include a respective section in their README

My perspective: I think this issue occurs due to our limited view or ability to fetch & process this information. We try to press everything into linkable files, but reality has shown to be different. I wouldn't enforce a format in the specification, just because it's otherwise hard for us to fetch the information. Projects have their specific needs and hence also BoM-concepts.

So I personally would be fine just referencing the information in whichever form it may be provided

[hoijui]

See also this: https://github.com/OPEN-NEXT/OKH-LOSH_copy/issues/73

(thanks Moe for hinting at it)

[hoijui]

Bob from ValueFlows hinted me at a CSV standard format that exists, but its definition is non open.

[hoijui]

if a project would come with a ValueFlows recipe as its manufacturing-instructions, that would already (always/usually?) include something like a BoM, just more elaborate.

[fosterlynn]

Yes, VF recipe has both the manufacturing instructions and the BoM plus other inputs like work, equipment usage.