PURL Support

This content originally appeared on DEV Community and was authored by Elizabeth Mattijsen

This is part 4 in the SBOM series of blog posts

While working on the SBOM::CycloneDX one of the fields caught my eye: purl. Initially I thought: “what does that have to do with our sister language”? It quickly became clear that this was about a Package URL.

Deeper into the rabbit hole

From the README:

A purl or package URL is an attempt to standardize existing approaches to reliably identify and locate software packages.
A purl is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases.
Such a package URL is useful to reliably reference the same software package using a simple and expressive syntax and conventions based on familiar URLs.

And the list of adopters is already pretty impressive.

But, as there was no support for PURLs in Raku yet, it also meant support for it had to be created. I decided to write the support it, which was also quite a task.

A PURL module

Since I wanted SBOM::CycloneDX to be able to support the entire functionality of the CycloneDX 1.6 definition, I had no choice but to implement the whole of the PURL specification (and its supported types) as well. Life can be hard when you’re having fun!

At the moment of this writing, the PURL specification recognizes 31 types, each with their rules for handling and interpreting their native package specification into a Package URL.

Fortunately a pretty large test-set was provided for all registered types. Which changed in format halfway through implementation, but that’s what you get when you’re at the bleeding edge of developments.

So there it was: PURL support for Raku. Which allowed the purl subset of SBOM::CycloneDx to get validation. For whatever SBOM thrown at it.

Adding support for Raku module distributions

But implementing all of this was not really of use for Raku module distributions itself. Because there was no support for Raku defined in the PURL specification itself yet.

I decided to wing it. Which was pretty easy, at first:

• type: “raku” (that was easy)
• namespace: that would be the “auth” of a Raku module distribution, e.g. “zef:raku-community-modules”
• name: that would be the name of the distribution, e.g. “MIME::Base64”
• version: that would be the version, e.g. “1.2.4”

So the Package URL (PURL) of the identity

MIME::Base64:ver<1.2.4>:auth<zef:raku-community-modules>

would be

pkg:raku/zef:raku-community-modules/MIME::Base6@1.2.4

as a Package URL. Easy enough, right?

Adding “raku” to the Package URL standard

But this was not enough of course: to make “raku” acceptable as a Package URL type, some work needed to be done. And that work has been done in the “Add Raku Programming Language as a purl-spec type”. And there’s hoping that my Pull Request (with specification, documentation and tests) to the Package-URL project will be merged soon.

Requirements versus Dependencies

Of course, there’s always a catch. If you look at the META6.json file of a Raku module distribution that needs other modules to be installed, you’re generally looking at a “requirement”. For instance, looking at the META6.json of Identity::Utils:

"depends": {
  "runtime": {
    "requires": [
      "String::Utils:ver<0.0.35+>:auth<zef:lizmat>"
    ]
  }
},

Notice the + in “0.0.35+”. This is Raku’s way of indicating: “any version higher than or equal to 0.0.35 will be acceptable”. Such an identity string does not actually indicate a dependency, because it doesn’t pin the actual version that will be used at runtime.

So how would this translate to a PURL?

use PURL;
say PURL.from-identity("String::Utils:ver<0.0.35+>:auth<zef:lizmat>");
# pkg:raku/zef:lizmat/String::Utils?vers=vers:raku/%3E=0.0.35

That doesn’t look at all like “pkg:raku/zef:lizmat/String::Utils@0.0.35+”! That’s because PURLs use a more generic way to indicate version ranges, using the VErsion Range Specifier standard.

Yet another rabbit hole to dive into. But more about that in the next blog in this series.

Conclusion

The Package URL specification attempts to reliably identify software packages. Raku support for this standard was lacking in software, and in the standard. The former has been addressed in the PURLdistribution , the latter is awaiting approval in a Pull Request.

This content originally appeared on DEV Community and was authored by Elizabeth Mattijsen