[heavenlyhash]

soo..... what's the guidance for when package names include a slash?

such as approximately everything in golang, which very often matches e.g. "github.com/*" as a package name?

Do would PURL suggest that "github.com/foobar/go-whatnot" should be parsed as namespace="github.com" (odd) and package name "foobar/go-whatnot" (since there aren't any more slashes in the blessed separators)?

[layer8]

The canonical answer would be percent-encoding, so pkg:golang/github.com%2Ffoobar/go-whatnot.

https://en.wikipedia.org/wiki/Percent-encoding#:~:text=accor...

[pombreda]

Encode the slash as explained in the clarified spec https://github.com/package-url/purl-spec/pull/453 :)

We are working on further clarifying Golang which a bit problematic: there is really no name or namespace in Go, just a path, and it is not possible at scale to tell when a Go module stops and when a Go package starts just by looking at the path... this is going to be clarified after the merge of the PR 453.

[heavenlyhash]

My 2c (opinions may vary, etc, etc): I think that doing percent-encoding shenanigans is going to be widely perceived as "ugly" and will severely hamper adoption. I'd reconsider.

I think it's quite likely that people are going to care a lot (lot) less about the semantic distinction between <namespace> and <name> (which is a semantic, handwavey, somewhat indistinct subject to begin with) than they are going to be turned off by percent encoding.

There's two broad categories of possible outcome for that kind of friction:

- Either people-in-the-wild do implement and obey the percent encoding rule, despite the friction (and adoption gets a debuff);

- Or, people-in-the-wild will just quietly ignore the percent encoding rule. And I think this is significantly likely, considering that (iiuc) the only consequence is that the parts with slashes end up considered <name> and never <namespace>.

Neither of those outcomes is totally bad, but they're both unfortunate. For the first one, an adoption debuff is never great. For the the second one (e.g. rule mostly ignored), there's other potential negative outcomes: the community might be fractured; and also, that figuring out what to do when writing a good renderer and some people followed the percent-encoding rule and some didn't... is going to be very, very ugly.

On the other hand, if the spec doesn't recommend (or support) percent encoding at all... yes, it loses the ability to express some <namespace> values. But is that actually something that's truly load-bearing? Maybe dropping that expressability is actually a viable trade.

[pombreda]

Disclosure: I created that spec and we are working hard to clarify it and remove grey areas!

[conradludgate]

I don't know, but I imagine those are actually the namespace. Eg I would imagine pkg:go/github.com/foo/bar@1.0.0 To be package bar in the github.com/foo namespace.

The distinction doesn't really seem to matter much between namespace and name in all honestly.

[pombreda]

Agreed. In hindsight, I always wonder if this was a good idea to have this split. At least the namespace is optional and required only certain package types

[Joker_vD]

What's the guidance when URI paths include a slash?

    pkg:github.com%2Ffoobar/go-whatnot

[pombreda]

This is not a valid PURL as it is missing a type, assuming you wanted golang here.

It could be instead:

    pkg:golang/github.com%2Ffoobar%2Fgo-whatnot