I don’t think it’s possible to have a canonical purl for Nix; there can be multiple flakeRefs that produce the same package. However, I don’t think system plays any role here; p = p' ⇒ p.system = p'.system.
And, if we disregard all qualifiers, then purl(p) = purl(p') ⟺ p = p', and there’s no need for any canonicalization.
I think I tend to agree here; there’s no real need for a separate system qualifier, as it is already part of the “version” in a way. I’ll drop it from the proposal.
I agree that purl and Nix aren’t made for each other, and the work you’re linking looks better and probably works better too. However, I think we can still have some purl for Nix, even if it’s ugly; the two solutions are not mutually exclusive.
I agree with @balsoft here. Sure, the information is more nicely represented in the CycloneDX properties, but that doesn’t mean PURLs are useless. For one, they are more cross-platorm, SPDX supports PURLs too for instance. Also, as much as I don’t like it, many vulnerability scanners rely on the PURL to perform their lookups.
Perhaps we should actually harmonize both efforts, and have the same fields as purl attributes and as CycloneDX properties as much as possible?
We might be able to unify some fields. But generally, I don’t think that would work. The properties are just that, properties of the component. The PURL is supposed to uniquely identify a package, without any other data.
Sorry if this is too lazy of a question, but what are examples of tools that would benefit from being able to refer to nix packages via PURLs?
RE: Hashes
Just an observation: with Nix it’s trivial to identify “concrete” packages, but Nixpkgs doesn’t offer much tooling for reasoning about “different versions of the same package”