4 ms·

This situation arises solely from Go's myriad dependency management tools [1], including the latest "official experiment" 'go dep', not having the notion of a p

This situation arises solely from Go's myriad dependency management tools [1], including the latest "official experiment" 'go dep', not having the notion of a package repository. Instead, package identity is tightly bound to package location [2], and doing "package management" on this identity results in HTTP GETs or equivalents to that location. This is documented as a core convention [2] of the Go world, by the designers themselves. I was always bewildered by this choice [3][4], because many, many other package management systems have independently realized this to be a bad idea -- and that it's valuable to have an extra layer of indirection between package identity and package location to prevent this exact situation. The component that solves this indirection is called a package repository, which can then institute strict rules about immutability, deletions, and naming, if so desired. NPM didn't, for a long time, until they got burned. GitHub is not a package repository, but due to the Go community's guidance, is effectively being used as such in a large volume of Go code in the wild. [1] https://github.com/golang/go/wiki/PackageManagementTools https://github.com/golang/go/wiki/PackageManagementTools [2] https://golang.org/doc/articles/go_command.html#tmp_1 https://golang.org/doc/articles/go_command.html#tmp_1 [3] https://news.ycombinator.com/item?id=12189356 https://news.ycombinator.com/item?id=12189356 [4] https://news.ycombinator.com/item?id=15677338 https://news.ycombinator.com/item?id=15677338

cdoxsey 9y ago
You can override the location of a package with dep. Indirection doesn't solve the problem it just moves it to the centralized repository. Go designers recommend vendoring packages which solves the problem.
- niftich 9y ago
  > "You can override the location of a package with dep." As far as I know, this is true [1], and can be done with the 'source' rule in Gopkg.toml. However, the guidance for dep says [1]: "A source rule can specify an alternate location from which the name'd project should be retrieved. It is primarily useful for temporarily specifying a fork for a repository. source rules are generally brittle and should only be used when there is no other recourse. Using them to try to circumvent network reachability issues is typically an antipattern." This doesn't sound like a glowing endorsement of this feature. > "Indirection doesn't solve the problem it just moves it to the centralized repository." Precisely; we're in agreement. A repository can then choose to institute sensible rules, if they so desire: Maven Central has what I would consider to be sensible rules, while NPM prior to 'left-pad' did not. Without a repository, the community has no place to make this decision point, so everyone's left to fend for themselves. > "Go designers recommend vendoring packages which solves the problem." Can you point me to guidance from Go designers which substantiates your point? I have been searching for this and have been unable to find it. [1] https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
  - cdoxsey 9y ago
    From the faq: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version > If you're using an externally supplied package and worry that it might change in unexpected ways, the simplest solution is to copy it to your local repository. (This is the approach Google takes internally.) Store the copy under a new import path that identifies it as a local copy. For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg". The gomvpkg program is one tool to help automate this process.
    - Shoothe 9y ago
      I think Google doesn't see the problem because they have internally all their dependencies copied locally. There is no fetching of external sources so for them the problem that some dependency URL is broken simply does not exist.
- imtringued 9y ago
  You can host your own repository and have full control over it without having to override all the github links to your internal links.
brown9-2 9y ago
What would a Go package repository host? Bundles of source code? Object files?
- petre 9y ago
  Bundles of source code, like CPAN and npm uses. Otherwise you'd have to ship binaries for every platform.

cdoxsey 9y ago

You can override the location of a package with dep. Indirection doesn't solve the problem it just moves it to the centralized repository. Go designers recommend vendoring packages which solves the problem.

niftich 9y ago
> "You can override the location of a package with dep." As far as I know, this is true [1], and can be done with the 'source' rule in Gopkg.toml. However, the guidance for dep says [1]: "A source rule can specify an alternate location from which the name'd project should be retrieved. It is primarily useful for temporarily specifying a fork for a repository. source rules are generally brittle and should only be used when there is no other recourse. Using them to try to circumvent network reachability issues is typically an antipattern." This doesn't sound like a glowing endorsement of this feature. > "Indirection doesn't solve the problem it just moves it to the centralized repository." Precisely; we're in agreement. A repository can then choose to institute sensible rules, if they so desire: Maven Central has what I would consider to be sensible rules, while NPM prior to 'left-pad' did not. Without a repository, the community has no place to make this decision point, so everyone's left to fend for themselves. > "Go designers recommend vendoring packages which solves the problem." Can you point me to guidance from Go designers which substantiates your point? I have been searching for this and have been unable to find it. [1] https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
- cdoxsey 9y ago
  From the faq: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version > If you're using an externally supplied package and worry that it might change in unexpected ways, the simplest solution is to copy it to your local repository. (This is the approach Google takes internally.) Store the copy under a new import path that identifies it as a local copy. For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg". The gomvpkg program is one tool to help automate this process.
  - Shoothe 9y ago
    I think Google doesn't see the problem because they have internally all their dependencies copied locally. There is no fetching of external sources so for them the problem that some dependency URL is broken simply does not exist.
imtringued 9y ago
You can host your own repository and have full control over it without having to override all the github links to your internal links.

brown9-2 9y ago

What would a Go package repository host? Bundles of source code? Object files?

petre 9y ago
Bundles of source code, like CPAN and npm uses. Otherwise you'd have to ship binaries for every platform.