-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: dependency graph in SBOM result #40
Comments
Support for dependency graphs should be included in every official CycloneDX implementation, including this one. Currently, only the Maven plugin supports it. I'm relying heavily on the community for these types of enhancements. PR's are highly encouraged. |
How does this look
I have rough implementation of this, will open a PR soon. This is in reference to https://cyclonedx.org/ext/dependency-graph/ . That page says "It has been incorporated (with minor changes) into CycloneDX v1.2 and higher. #" Could someone point me to the "minor changes" ? |
The dependency graph extension should not be used. Rather, the built-in dependency graph elements should be used instead. This is going to require #9 to be implemented. The 'minor change' is actually with regard to #9 - the metadata section. The dependency graph example provided in #40 (comment) is not capable of describing direct vs transitive relationships. The 'minor change' in v1.2 is that the dependency graph can now make that distinction. Refer to https://cyclonedx.org/use-cases/#dependency-graph |
@stevespringett thanks for the links . Correct me if I am wrong: to translate the v1.2 spec to python world, the Also could you elaborate
does that simply mean |
Correct |
@sbs2001 , were you able to raise PR for above? Thanks |
Leaving this open as some work may be required in this application for outputting dependency graphs once |
I'm struggling to understand the current state of this feature. It seems like the library supports this now, but there's still some work left on this side of things, correct? If so, would it be a good idea to work on #303 and go from there, or does it need a new attempt? I'd love for this feature to finally make it into the tool and am willing to help out. |
re: #40 (comment) |
I have had reason and time to look at this again, and now I understand how... thorny this can be. I think I can port the work from #303 onto a newer version of the source, so that the poetry and environment parsers will support it, and I have a PoC for how to do it from a Should I just open a branch with all of these changes, as a proposal? Or should I leave the |
related: #487 (comment) this shows an idea how to create a dep tree from @madpah FYI |
will be part of upcoming v4 |
fixed by #605 |
This feature will be part of the next/upcoming major release. |
Will there be added support for the dependency graph extension, or will that be a separate library?
The text was updated successfully, but these errors were encountered: