Julia PURL: UUID requirement discrepancy

[s-celles]

Hello,

pkg:julia/Dates or pkg:julia/NanoDates (without UUID) are rejected by PackageURLs.jl but accepted by other parsers (e.g., package-url-viewer which use packageurl-js)

Current test fixture (julia-test.json) marks it as invalid:

{
  "description": "invalid julia purl for package without uuid",
  "input": "pkg:julia/Dates",
  "expected_failure": true
}

Question: Is this a test fixture bug? Other PURL implementations appear more permissive.

Action: Check if julia-definition.json defines UUID as "requirement": "optional". If so, the test fixture could be incorrect.
Edit: It's required from

purl-spec/types/julia-definition.json

Line 30 in 565d7f1

"requirement": "required",

Related: #789, purl-types-index.json, #540, #795

My opinion (which may be of very low importance) is that, as there is only one default Julia General Registry and one package with a unique name in this registry, uuid should be optional in order to have PURL quite short

Let's take pkg:julia/NanoDates as an example:

https://s-celles.github.io/package-url-viewer/?purl=pkg%3Ajulia%2FNanoDates points to
https://juliahub.com/ui/Packages/General/NanoDates

Pinging @Octogonapus and @mjherzog

I think situation should be fixed according decision:

• if uuid are required then packageurl-js need to be stricter (or that's a mistake in my package-url-viewer implementation)
• if uuid are not required then julia-test.json and PackageURLs.jl need to be more lenient

Any opinion?

[s-celles]

Here is an other example of permissiveness of Python PURL implementation with a PURL of a Julia package

❯ ipython
Python 3.13.5 | packaged by Anaconda, Inc. | (main, Jun 12 2025, 16:37:03) [MSC v.1929 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 9.10.0 -- An enhanced Interactive Python. Type '?' for help.
Tip: You can use `%hist` to view history, see the options with `%history?`

In [1]: from packageurl import PackageURL

In [2]: purl = PackageURL.from_string("pkg:julia/NanoDates")

In [3]: purl.to_dict()
Out[3]:
{'type': 'julia',
 'namespace': None,
 'name': 'NanoDates',
 'version': None,
 'qualifiers': None,
 'subpath': None}

If all implementations are expected to follow tests, they should all raise error on this... (not only PackageURLs.jl)

Proposed plan:

1. Decide whether uuid are really required here for Julia package PURL or not (what ever answer is, go to 2.)
2. Ensure all current implementations fail with pkg:julia/NanoDates (yes they should according tests whatever answer to 1. is)
3. Fix, if that's not the case, implementations that "don't respect tests"
4. Back to answer 1. and see what need to be done according answer of 1.
5. If answer of 1 is "we MUST have uuid", then nothing more to do
   If answer of 1 is "uuid are optional in PURL for Julia", then some work need now to be done is all PURL implementation.

I'm aware that's not a quick task.

Edit: a last argument against uuid mandatory in PURL of Julia package, citing in a scientific paper will be badly very rendered for Julia packages ;-)

[mjherzog]

@s-celles I am not a Julia expert and I do not know the reason why the uuid qualifier was originally defined as required for the julia PURL type definition. I defer to @Octogonapus for that point.

I can say that that requiring a 'uuid' qualifier should be revisited because requiring data other than scheme, type and name is problematic for many vulnerability use cases. Recently we have seen several requests to register a new PURL type with version required. In those cases we engaged with the requestor to change version to optional because of the vulnerability use case.
It may be the case that we need to update the PURL spec so that qualifiers are optional and we could apply that change to the registered PURL type definitions and new PURL type registrations in the meantime. I will raise this at our next TC54-TG2 (PURL) meeting (meeting schedule is at: https://www.packageurl.org/docs/participate/participate-meetings).
There is a related set of discussions about upgrading the PURL test suite

• Upgrade PURL test suite

The related points from the test suite project are:

• Clearly distinguishing between base tests required for conformance and advanced tests that are more flexible.
• Adding the concept of registering recommended values for namespace or qualifiers at the PURL type level.
• Providing the structure for advanced tests that can provide validation messages so that for Julia an advanced test could produce a warning that a uuid is recommended. The base tests would be pass/fail based on the spec and PURL type definition.

[s-celles]

https://www.packageurl.org/docs/participate/participate-meetings

raises 404

https://www.packageurl.org/docs/participate/participate-meetings.html

Is correct (but maybe first url should be used according principle of so called clean URLs (also known as pretty URLs, RESTful URLs, or human-friendly URLs).

100% agree with you... we don't need to make uuid mandatory in Julia PURL (at least this have to be revisited)

[s-celles]

I saw some answers on https://julialang.slack.com/ #security-dev
Pinging some Julia experts about this current UUID requirement in PURL @StefanKarpinski @mbauman

[mjherzog]

@s-celles The URL error was just a copy/paste error on my part.

[s-celles]

I mean the right url should ideally be https://www.packageurl.org/docs/participate/participate-meetings not .html because "human friendly urls" (or Cool URIs) hide technology being used (html, php, cgi ...)

The foundational source is **Tim Berners-Lee's 1998 essay**:

**"Cool URIs don't change"**
https://www.w3.org/Provider/Style/URI

He argues that URIs should be designed to last decades, and that including implementation details like file extensions (`.html`, `.cgi`, `.php`) is a mistake because they tie the URL to a specific technology that will inevitably change.

His key quote: *"What makes a cool URI? A cool URI is one which does not change."*

This was later formalized more technically in the **W3C's "Architecture of the World Wide Web, Volume One" (2004)**, which distinguishes between a *resource* (an abstract thing) and its *representation* (HTML, JSON, etc.), reinforcing that URIs should identify resources, not file formats.

[DilumAluthge]

This was discussed in the Julia Slack. My opinion (and @StefanKarpinski concurs) is that the canonical way to unambiguously identify a Julia package is by name+UUID, so I think the Julia PURL type should require the UUID.

[mjherzog]

@DilumAluthge Thank you for the input. If the canonical way to identify a Julia package is by "name+UUID" then this suggests that the PURL name component for a Julia package should itself be "name+UUID".

[s-celles]

@mjherzog Did you see the conversation on Julia Slack?

One argument that emerged from discussion was how registry can tackle package name reuse and what is policy about same name in a Julia general registry.

Should all packages be affected to have such a long PURL when it only affects some exceptions (where uuid will be needed in PURL to disambigous them from "original" package)?

An argument was:

It also adds the ability to refer to packages that are not in General

I think we could have possibility to refer to a package that is not in General without imposing uuid. It could be done like so

pkg:julia/RegisterQD@0.3.1?repository_url=https://github.com/HolyLab/HolyLabRegistry

The question of recycling package name by registries should impose some rules on new packages. They should use version number which is superior to last abandoned package.

Maybe recycling package name should allow reusing same uuid for new package but imposing a major version bump.

[GunnarFarneback]

I have no insight about PURL things but identifying a package by name + registry url seems not so robust:

• Other registries than General are not bound by the immutability guarantees given by General and might remove a package or package versions.
• Although the tooling doesn't yet support it, it's possible that one registry can have multiple packages of the same name in the future; the registry design and Pkg can handle it. General is not so likely to allow it in the future either but other registries very well may do it.
• The same package can be registered in multiple registries and I imagine that having multiple identifiers for the same package would be less than ideal.

[Octogonapus]

Sorry I do not have time to work on this at the moment, but I trust in @DilumAluthge and @StefanKarpinski and agree with their suggested direction.

[mjherzog]

@s-celles I did not check the Julia Slack (trying to keep a lid on the number of my Slack workspaces) but that seems to be the right forum for the Julia community to come to a consensus. I can join there as needed.

All,
The current PURL spec allows a wide range of optional qualifiers (key-value pairs) so adding a 'repository_url' qualifiers field to a PURL is always an option. The core question for this particular issue is whether the 'uuid' qualifiers field should be required for any Julia PURL string to pass the base tests for conformance. I am also aware that redefining the name for a PURL package as "name+uuid" is visually awkward at best.

Regarding: "The same package can be registered in multiple registries and I imagine that having multiple identifiers for the same package would be less than ideal." It is common to see multiple PURL strings for the "same" package where the difference is the level of detail provided with qualifiers and possibly down to the subpath level.

I took a look at OSV.dev and see that most JLSEC advisories there include 'uuid' in the PURL. This seems to support the requirement for including a 'uuid' in a Julia "Base PURL" for vulnerability reporting if that will be the standard for Julia Security Advisories. On the AboutCode side we are tracking the status of Julia Security Advisories at aboutcode-org/vulnerablecode#1986. It seems that the design and implementation of Julia SecurityAdvisories is still a work in progress.

I will raise the broader issue:

• Schema change: Update specification and schema to make all qualifiers optional #808
  at one of the next PURL TG2 or Community meetings (see https://tc54.org/purl/ for meeting dates and coordinates) - which one depends on the other agenda items.