-
Notifications
You must be signed in to change notification settings - Fork 23
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: enable repo finder to support more languages via Open Source Insights #388
Conversation
f7fadaa
to
57d13c9
Compare
@@ -31,9 +29,13 @@ class DependencyTools(str, Enum): | |||
class DependencyInfo(TypedDict): | |||
"""The information of a resolved dependency.""" | |||
|
|||
version: str | |||
group: str | |||
scheme: str |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of duplicating the PURL spec here, wouldn't it be better to store the PURL string directly, which will be parsed using the packageurl
module later before analyzing the dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we store the PURL string as well as the old information (in their fields), we have duplicates. If we don't keep the old information, we have to create the PURL from the string every time we want to extract any information from it. Perhaps storing the actual PURL would make the most sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the option of storing the actual PURL object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Storing a PackageURL
object sounds good to me.
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
- Moved dependency resolution functions to dependency_resolver.py - Moved find_valid_url to repo_finder to avoid circular dependencies - Added URL for deps.dev API documentation as comment Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
… use with Repo Finder. Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
… string replacement in java repo finder Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
Signed-off-by: Ben Selwyn-Smith <[email protected]>
a8ccd34
to
bca62d5
Compare
Signed-off-by: Ben Selwyn-Smith <[email protected]>
These changes were to separate the resolving dependencies using SBOM generator and resolving dependencies from SBOM files. These changes were necessary for this PR back when I first work on it (before the merging of #388). However, after #388 is merged and further discussion, this change is no longer necessary. Signed-off-by: Trong Nhan Mai <[email protected]>
…sights (#388) This feature modifies the Repo Finder, so that it can: be usable from anywhere within Macaron; accept PURL strings as input; and, support more languages via Google's Open Source Insights (deps.dev) This enables Macaron to accept artifact PURLs as input, whereby the Repo Finder will be used to attempt to retrieve the related repository. Additional languages include those supported by deps.dev: Python, NodeJS, .Net, and Rust. Note that currently these will only work when specifying an artifact PURL as input, or providing an SBOM. Full support for these extra languages will require the addition of new dependency analyzers. A new config option is also provided to disable API calls to Google's Open Source Insights, if desired. Signed-off-by: Ben Selwyn-Smith <[email protected]>
The repo finder is refactored to:
Added languages include: Python, NodeJS, .Net, Rust.
Note that these additions won't do anything until dependency analysers for these languages are added.
Use of Open Source Insights can be disabled via a configuration value.