Authorities and private registries

[jackfirth]

Many companies run private deployments of package registries, and the names of packages in those registries are often both:

1. Entirely unrelated to the corresponding package with the same name in the well-known public registry
2. Only available at a private IP address

Suppose that I publish and consume private packages such as this. How would I mint PURLs that refer to these packages? If I can, how do I ensure they aren't confused with PURLs referring to the same package name in the public registry? If I can't, does that mean I can't ever use tools built on PURLs?

[pombredanne]

@jackfirth if such a company were to reuse pypi:django:1.11.1 as the naming for a private karaoke Python package to sing along Django Reinhardt great guitar tunes, then this would be an evil violation of the package management prime directive IMHO. e.g. Though shall not reuse other's names and versions for a different thingie. That said we can still accommodate such goofy and evil ways with these fine purl strings:

• pypi:django:1.11.1?repository_url=https://192.168.0.1 pointing to a private registry using a qualifier
• pypi:django:1.11.1?download_url=https://192.168.0.1/music/karaoke/guitar/django-1.11.1.tar.gz pointing to a private download using a qualifier

Both of these possibly common qualifiers are listed in https://github.com/package-url/purl-spec/blob/d31af66785896bd42dd9467b14bf9352f8f1abfe/README.rst#known-qualifiers-keyvalue-pairs FYI

[jackfirth]

That stance means it's impossible to reliably define private namespaces, which severely limits the use of PURLs. What would be the point of using PURL tooling if I can't get it to work with my private packages the same way it does with my public packages? And why should my completely internal private packages be beholden to someone in the public package registry happening to pick the same name as one of my private packages? How am I supposed to stop that from happening while keeping my packages secret? And what if I want to use the same name with different authoritative namespaces, which happens all the time when a closed-source package is made open source and vice-versa?

Turning each package system into a completely unscoped global namespace seems unnecessarily inflexible, and sticking an entirely separate URL used for location inside a PURL makes me wonder why PURLs are URLs in the first place. It means standard existing URL libraries and tools can't work on a PURL without extra effort, even if that PURL specifies it should be downloaded with a common and well-known scheme like http.

[pombredanne]

you are perfectly entitled to create private namespaces and use the namespace component for this if you feel like it. But the common use case where I use the public central package repo for a given type stays simple. You can make your internal private cooking alright otherwise, but it will not be as clean and simple as the common use case which is perfectly fine by me: there are millions of programmers using these public package every day and a few 100K at most that may use goofy private things. I do not prevent this and I do not try to solve any of their naming problems. That's not the point here!

Unrelated, while I personally prefer to spell purl lower case rather than upper-case PURL, I like that you also spell it upper-case... because both are entirely correct in contrast with the URL that should be uppercase always ;) and it is perfectly OK to use pUrL too

[jackfirth]

If you want to keep the common use case simple you can still do that. Just have each package system define what its default authority is. A scheme registration should define what the default authority and port are anyway, so I don't think this makes things simpler for the common case and it makes many important and less common (but not rare) cases more difficult to support.

URI schemes are forever. You don't really get to fix bugs and corner cases in the spec once client software depends on the current behavior of those bugs and corner cases.

[pombredanne]

A URL scheme registration has to define what the default authority and port are anyway, so I don't think this makes things simpler for the common case and it makes many important and less common (but not rare) cases more difficult to support.

What is the Authority for tel: and mailto: ?

[jackfirth]

What is the Authority for tel: and mailto: ?

1. A scheme is allowed to specify that it has no authority, but that's generally reserved for cases where the scheme defines a resource that can't be retrieved over the internet (or at least usually isn't)
2. The mailto: scheme uses the user@host authority form
3. The tel: scheme falls under the case of 1 and as such does not define an authority

More broadly, these two schemes are bad examples to base PURLs off of. The mailto scheme must keep compatibility with mail address formats that existed long before URIs did. If it were defined today there's a good argument that it should be mailto:gmail.com/alyssaphacker instead. The tel scheme, meanwhile, must be compatible with phone number standards that are managed by an entirely different standards organization not under the authority of the IETF; specifically, the International Telecommunication Union agency of the United Nations.

But almost all package protocols use HTTP already. Attempting to reuse HTTP notions of authorities, the Web Origin concept, dynamic links, and unambiguously self-descriptive messages will all yield a lot more benefit for PURLs than for email and phone identifiers.

[pombredanne]

ok, so let's say we allow authorities in a purl. Say to point to an alternate or private package repository/registry.

Is this enough to point to the proper place? What if you need to also add a Path and Query to full qualify this repo? Most repos may need this and I cannot assume that only a host is enough to reach a registry.

If you start to reuse parts of the Path and Query components, then the purl non ambiguous definition falls apart flat IMHO: I can no longer distinguish what are the parts that are defining a package repo from the parts that identify and name a certain package because the Path mixes things from these two separate concerns.

[pombredanne]

So unless you think we are in a dead end I think we cover the various use cases: default alternate and/or private registries are supported alright, and their support is flexible enough. See also #14 and #27
Is there still something that might not be covered before we can close this?

[rarkins]

I also have concerns with this and see there is some overlap with #27 where the host is essentially part of the public scheme.

Examples I am hitting up against:

• specifying repositories in self-hosted github, gitlab, etc
• private npm registries like artifactory

[jdillon]

Would it help to consider basic package-url as an identifier for what the thing is, vs. where it comes from?

It may help to have a sub-spec of qualifiers that may help identify where something comes from and leave the proper package-url to identify what the thing is?

FTR the main value package-url has for use I have seen for is a normalized way to identify what something is, with extractable coordinates (namespace, name, version).. not where it comes from

[Insidexa]

Any updates? We use private registries for npm, Gradle, and PyPI, and in the GitHub UI, we don't have links to custom libraries