Let’s debabelize the way we identify and locate software packages across tools, databases and APIs with the new purl a.k.a. package URL!
We build and release software by massively consuming and producing software packages such as NPMs, RPMs, Rubygems, etc. Each package manager, platform, type or ecosystem has its own conventions and protocols to identify, locate and provision software packages.
When you need to track and store information for various packages, it is difficult to reference these across tools and package “ecosystems” in a clear and uniform way.
The purl aka. “mostly universal” package URL is born from a grass-root initiative to provide a simple spec and libraries and solve this problem: standardize existing approaches to reliably identify and locate software packages.
A purl is based on the expressive syntax of familiar URL strings: these are easy to grok for humans and machines alike and can work consistently across programming languages, package managers, packaging conventions, tools, APIs and databases.
A purl could be useful:
- To reliably reference the same software package across inventory and scanning tools, .
- In cross-system metadata indexing, aggregation or alerting systems that collect, catalog and monitor packages information such as versions, dependencies, licensing, etc. across multiple package managers,
- When tracking known vulnerabilities of a package or its dependencies, and eventually relate the multiple incarnations of a code package across packaging systems,
- And many other kinds of analysis, such as building dependency graphs of packages, etc.
Want to learn more?
- Get started with purl at github.com/package-url/purl-spec
- Explore a database of purls at github.com/nexb/purldb and a dataset of purl for offline lookup and verification usage at github.com/nexb/purldb-data
- Explore other FOSS projects at AboutCode.org
