> "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.
> 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.
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.
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