Pr\"azi: From Package-based to Call-based Dependency Networks

TL;DR

Pr"azi enhances dependency network analysis by combining package manifests with call graphs to reveal actual usage patterns at the function level, providing more accurate insights into package dependencies.

Contribution

This paper introduces Pr"azi, a novel approach that constructs function-level dependency networks by integrating manifests and call graphs, improving dependency usage understanding.

Findings

Packages call only 40% of their resolved dependencies

Metadata-based networks overgeneralize dependency usage

Manual analysis shows dependency use varies significantly

Abstract

Modern programming languages such as Java, JavaScript, and Rust encourage software reuse by hosting diverse and fast-growing repositories of highly interdependent packages (i.e., reusable libraries) for their users. The standard way to study the interdependence between software packages is to infer a package dependency network by parsing manifest data. Such networks help answer questions such as "How many packages have dependencies to packages with known security issues?" or "What are the most used packages?". However, an overlooked aspect in existing studies is that manifest-inferred relationships do not necessarily examine the actual usage of these dependencies in source code. To better model dependencies between packages, we developed Pr\"azi, an approach combining manifests and call graphs of packages. Pr\"azi constructs a dependency network at the more fine-grained function-level, instead of at the manifest level. This paper discusses a prototypical Pr\"azi implementation for the popular system programming language Rust. We use Pr\"azi to characterize Rust's package repository, Cratesio, at the function level and perform a comparative study with metadata-based networks. Our results show that metadata-based networks generalize how packages use their dependencies. Using Pr\"azi, we find packages call only 40% of their resolved dependencies, and that manual analysis of 34 cases reveals that not all packages use a dependency the same way. We argue that researchers and practitioners interested in understanding how developers or programs use dependencies should account for its context -- not the sum of all resolved dependencies.