-
Notifications
You must be signed in to change notification settings - Fork 314
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
Take a look at Google's Insights project (https://deps.dev/) #4112
Comments
Their FAQ is a very interesting read: Most of the back end is written in Go and reimplements the dependency analysis algorithm (version resolution) of each packaging system. The code has been tested for agreement with the native tooling, but is faster because it is decoupled from package installation. It constructs the graph without actually building and installing the software." |
Sofar insights projects only npm, Maven, Go modules, and Cargo for which static analysis should work really well (apart from maybe Go). Would be interested to learn how they did Go support and how they are planning to do PyPI. |
I'll share what can be learned from their response once I get it. |
Insight's data is now also available via BigQuery. Maybe this data could be used by the Analyzer to speed up the lookup of package metadata. |
BTW, I never heard back from them, so I just reached out again. |
BTW, the deps.dev people posted a great blog article that highlights the importance of "context" during dependency resolution, but their API currently doesn't offer a way to provide this context. |
@sschuberth I have actually implemented an identical mechanism about a year ago in Python and Neo4J. From my experience, aside from it being cool and all, you need a very large infrastructure that's being updated with new version releases (which even deps.dev doesn't do - they update maybe twice a year) and a complex resolution logic to match the actual tree to the one generated by the package managers (which depends on the context of where the package is used and alongside which other packages). In other words, it's not a practical solution unless you have a lot of money and research invested in it on a dedicated central infrastructure. You can't get the exact picture of the dependency tree unless you use the native package managers resolution mechanism. |
I absolutely agree @Aponace, and that's why ORT's analyzer has always aimed to use the native package manager's resolution mechanism. However, it was brought to my attention that several ORT users are not necessarily interested in the exact picture, but something "close enough" (that can be determined much faster) is sufficient. From a license compliance aspect, that might even be true, as licenses usually do not change between "similar" package versions. But from a security compliance aspect, that might be a problem, as also patch level package versions may introduce severe security risks. |
Their new API now also supports PURLs. |
Also @jamietanna's Dependency Management Data (DMD) seems to be using deps.dev, which might be an interesting integration point. |
Thanks Sebastian, yes, you should be able to use DMD alongside ORT (https://dmd.tanna.dev/cookbooks/getting-started-ort/) in the meantime to get this data! But would be great to have first-class support |
@jamietanna Just to mention, the docs are outdated, we moved from ort-extended to ort a while ago. |
Thanks! I'm on holiday for the next week, but can look to update when I'm home. Or I'd welcome a Merge Request on GitLab if you were happy to update for me ☺ |
Google just announced the Insights project. In large parts it has similarities with ORT's analyzer and advisor components, and pages like this one have similarities with the web app report.
I'll reach out to the Insights team to learn about how they are doing things.
The text was updated successfully, but these errors were encountered: