Closed houdini91 closed 7 months ago
The following is @manifestori his original reply, You've raised several ideas and I would like to address all of them:
dedicated commands for cdx/spdx. I would argue that's less intuitive, as cdx is used alongside cyclonedx will cause confusions. then, renaming command to sbom-convert cyclonedx sbom.spdx.json is less ergonomic then sbom-convert sbom.cdx.json Also note that I did not use a format as I'm utilizing the "reverse" functionality - detected format and choosing the reverse. without it - sbom-convert -f spdx sbom.cdx.json In addition I removed the "convert" as it would be the default command. (sbom-convert convert == sbom-convert)
Supporting uri is a good idea, but some users just wants to sbom-convert -f spdx sbom.cdx.json and including the long uri values is just a tiny bit more of a "power user" feature. So having us supports both, makes sense to me.
Sourcing supported formats, and encoding directly from protobom is a cool feature. It requires some string manipulations if we want to convert it to supported encoding/formats/versions which makes sense. however doing it programmatically is a bit overkill as we're not dealing with 5 new formats a month. Even if we do supports this, we need protobom lib to expose a function or a map of supported uri we can pull from, then on a new release, we will need to upgrade sbom-convert with a PR anyway, I don't think its critical or cannot be resolved manually.
I do agree that sourcing CLI usage options from the same variable will make upgrade much easier, but this is also out of scope for this initial PR :D
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue was closed because it has been stalled for 5 days with no activity.
@manifestori i think its worth discussing in a issue. Comment was taken from pr https://github.com/bom-squad/sbom-convert/pull/3
The issue: Because we have a dual kind of role for cdx and spdx sboms. we cannot really have default values for command line arguments but need to set them basically in runtime after we sniff out the input file format, i suggest breaking down the CLI in two so we can acutally set flags defaults according to a static command structure.
I try and write down what i was thinking and see if people view this differently. In order to simplify the CLI UX i think its best we break our CLI in to two subcommand one to translate spdx and another for cdx. This will allow simplify the way we up with acutal
pFlag
default values allowing the user to run the simplist of commandsbom-convert cdx my_cdx.json
andsbom-convert spdx my_spdx.json
, in turn this will simplify the usage help message to include said defaults for each subcommand.For example the subcommand cdx can look similar to the following, note the defaults of the falgs reflect the opposing format latest supported format.
Once the core library adds another format i would love for this usage to update once we pull in the new library (basing the content of the options and defaults from the underlining core library full format list as well as its default format list.
Another simplification i drop --encoding and --version and only support full uri including type,version and encoding in one string., and simplify default its value in to the underlining core library default value. So something like