Matt Donoughe

The steps in my comment are adapted from the parsing section of the spec: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst#how-to-parse-a-purl-string-in-its-components

> my UI also incorrectly parses the namespace segments when the slashes are encoded These screenshots show the namespace being parsed correctly according to the generic PURL rules. `pkg:golang/github.com%2Fquic-go%[email protected]` is...

I think the unfortunate thing is that PURL has a general concept of namespaces at all. `pkg:golang/github.com/quic-go/[email protected]` is an objectively better PURL-ification of `golang/github.com/quic-go/quic-go v0.40.0` than `pkg:golang/github.com%2Fquic-go%[email protected]`. From my perspective,...

Maven and Gradle and Sbt are only one case. It doesn't matter if it's a big case or not. The package type is only documented once. NPM does have scopes,...

CVE matching seems like it is always messy. For PURL I think typically [email protected] is expected to always be [email protected], not zlib1g@1:1.2.11.dfsg-1+deb10u2 or 1:1.2.11.dfsg-2+deb11u2 depending on what version of Debian...

I think the v is part of the version in Go and needs to be present. https://github.com/golang/go/issues/32945 If purls were written without the v and then Go started doing something...

The Go section of the spec is in dire need of updates. The version and subpath stuff there implies that it's talking about Go packages and Go modules aren't supported....

The spec is clear that Go packages have PURL namespaces, even if the concept does not exist in Go. What's missing is that Go packages only _sometimes_ have PURL namespaces...

I guess the problem with Go (and NPM) packages is that even if your PURL implementation is correct, it's up to the application to correctly handle this namespace/name split and...

#204 might be the way to go. Combine the namespace and name into one value at the PURL level, don't encode slashes¹, and leave it up to the package type...