Google Releases 'Open Source Insights' Dependency Visualization Tool (thenewstack.io) 11
From today's edition of Mike Melanson's "This Week in Programming" column:
If you've been using open source software for any amount of time, then you're well aware of the tangled web of dependencies often involved in such projects. If not, there's any number of tools out there that explore just how interconnected everything is, and this week Google has jumped into the game with its own offering — an exploratory visualization site called Open Source Insights that gives users an interactive view of dependencies of open source projects.
Now, Google isn't the first to get into the game of trying to uncover and perhaps untangle the dizzying dependency graph of the open source world, but the company argues that it is more so trying to lay everything out in a way that developers can see, visually, just how, well, hopelessly screwed they really are.
"There are tools to help, of course: vulnerability scanners and dependency audits that can help identify when a package is exposed to a vulnerability. But it can still be difficult to visualize the big picture, to understand what you depend on, and what that implies," they write.
The Open Source Insights tool — currently "experimental" — gives users either a table or graphical visualization of how a project is composed, allowing them to explore the dependency graph and examine how using different versions of certain projects might actually affect that dependency graph. One of the benefits, Google notes, is that it allows users to see all this information "without asking you to install the package first. You can see instantly what installing a package — or an updated version — might mean for your project, how popular it is, find links to source code and other information, and then decide whether it should be installed."
Currently, the tool supports npm, Maven, Go modules, and Cargo, with more packaging systems on the way soon...
Now, Google isn't the first to get into the game of trying to uncover and perhaps untangle the dizzying dependency graph of the open source world, but the company argues that it is more so trying to lay everything out in a way that developers can see, visually, just how, well, hopelessly screwed they really are.
"There are tools to help, of course: vulnerability scanners and dependency audits that can help identify when a package is exposed to a vulnerability. But it can still be difficult to visualize the big picture, to understand what you depend on, and what that implies," they write.
The Open Source Insights tool — currently "experimental" — gives users either a table or graphical visualization of how a project is composed, allowing them to explore the dependency graph and examine how using different versions of certain projects might actually affect that dependency graph. One of the benefits, Google notes, is that it allows users to see all this information "without asking you to install the package first. You can see instantly what installing a package — or an updated version — might mean for your project, how popular it is, find links to source code and other information, and then decide whether it should be installed."
Currently, the tool supports npm, Maven, Go modules, and Cargo, with more packaging systems on the way soon...
DLL hell (Score:3)
For years Linux people kept talking about DLL hell but it was never a problem. Dependencies are so bad now they had to invent containers because nobody but the author can compile it.
Re: DLL hell (Score:2, Interesting)
Bullshit. You clearly haven't used Linux. Ever.
Yes, we had dependency hell in the past. Which was almost never a problem. In 25 years, on many systems, I only had two cases that were not trivially but only easily resolved.
But ever since slotting was invented, multiple versions of a dependency are not a problem anymore.
Containers literally only exist, because Windows people live in such a bubble that they don't even want to understand anything else, and hence do not understand Unix.
Just look at Steam: Is it
Re: DLL hell (Score:1)
Yes, I am mad at arrogant stupid humans. Because I have evidence with probably six sigma statstical confidence by now, that they ruin the entire world.
Got a problem with that? (Feel spoken to?)
Re: (Score:2)
Oh yeah blame Linux dependency hell on single container from Steam. Did Steam invent the container? No, Linux developers did. Steam is using the container as designed.
I have first hand experience with dependency hell. Say program like KiCad doesn't have binaries for your distro. You can compile from source or try using one of the container systems they use. Oh the KiCad source needs a library and there is a package available, great! Oh but wait that library depends on another library without a package. Alri
Re: (Score:2)
I have used Linux for over 20 years, and yes libraries are real pain, especially when compiled from source.
I remember trying to download and build gnome alpha releases, and every time one library was done, the next one would break some older compiled ones. Even minor increments in the least significant version digit were breaking changes (i.e: 0.14.0.10 vs 0.14.0.11).
Hard working folks at Debian / RedHat / etc try to make sure everything runs together smoothly. However if something is not on the official re
sigh.... (Score:2)
This is just 'McCabe cyclomatic complexity' applied to dependency graphs. Soon I'm sure someone will "discover" that measuring the span is A Good Thing, and that well architected systems have a pattern to their graphs showing a small number of dependencies that connect/hide complexity within a subgraph.
Add this to the List of Things in Computer Science We've Forgotten.
Re: (Score:2)
his is just 'McCabe cyclomatic complexity' applied to dependency graphs.
Yes, but now the Google Children have (re)discovered it, so it's hip and cool and amazing.