4 ms·

Forgive me, but I don't get what the issue is. Surely the "ownership" of the domain is irrelevant? The package-name is just a unique name; the only thing it ref

Forgive me, but I don't get what the issue is. Surely the "ownership" of the domain is irrelevant? The package-name is just a unique name; the only thing it refers to is the package. In particular, I don't see any reason why the package-name needs to be related to the mailing-list/bugtracker, or to the location of the canonical code repository. XML uses URLs as labels for namespaces; they are just labels. Nobody expects to find a document about the namespace, nor a schema, at the namespace URL. There's never a need to resolve a namespace URL. Why should it be necessary to resolve a Go package URL? [Edit] I honestly don't know, because I've never used in Go.

moqmar 3y ago
Go uses the package name to retrieve the pagacke source - a package named github.com/example/whatever will be downloaded by basically cloning it with git & then checking out the specified version as a tag. That's in itself a really simple system and doesn't rely on a single third party, but obviously comes with the ownership issue (unless when pinning a specific commit) - in my opinion a good compromise.
Rygian 3y ago
There is a requirement to ensure all packages using the url-as-label are legitimate.
opaulo 3y ago
A Uniform Resource Locator (URL, RFC1738) is a name for localization and access of resources via the Internet. A Uniform Resource Name (URN, RFC8141 & RFC3986) is a name that identifies an abstract or physical resource. Your argument just favors distorting the concept of URL to use URL as URN. But if we were going to use URLs to identify abstract resources, why don't we use URNs instead?
usrbinbash 3y ago
> The package-name is just a unique name; the only thing it refers to is the package. Not quite. In go, you import 3rd party packages via a URL where a VCS can find them, eg.: import "github.com/gorilla/websocket" The package name is thus both, an unique name for the package AND a location where the toolchain can find and fetch it.
- denton-scratch 3y ago
  I see, thanks. Well, that's the problem, I guess. Someone famous once said "Good URLs don't change". Turns out he was pissing in the wind; nobody paid attention. And the market in DNS names guaranteed he'd be wrong.

moqmar 3y ago

Go uses the package name to retrieve the pagacke source - a package named github.com/example/whatever will be downloaded by basically cloning it with git & then checking out the specified version as a tag. That's in itself a really simple system and doesn't rely on a single third party, but obviously comes with the ownership issue (unless when pinning a specific commit) - in my opinion a good compromise.

Rygian 3y ago

There is a requirement to ensure all packages using the url-as-label are legitimate.

opaulo 3y ago

A Uniform Resource Locator (URL, RFC1738) is a name for localization and access of resources via the Internet. A Uniform Resource Name (URN, RFC8141 & RFC3986) is a name that identifies an abstract or physical resource. Your argument just favors distorting the concept of URL to use URL as URN. But if we were going to use URLs to identify abstract resources, why don't we use URNs instead?

usrbinbash 3y ago

> The package-name is just a unique name; the only thing it refers to is the package. Not quite. In go, you import 3rd party packages via a URL where a VCS can find them, eg.: import "github.com/gorilla/websocket" The package name is thus both, an unique name for the package AND a location where the toolchain can find and fetch it.

denton-scratch 3y ago
I see, thanks. Well, that's the problem, I guess. Someone famous once said "Good URLs don't change". Turns out he was pissing in the wind; nobody paid attention. And the market in DNS names guaranteed he'd be wrong.