I think the only realistic solution to this is to vendor your go dependencies. If Github ever changes its URL schema, a whole bunch of stuff is going to break.
The Go maintainers have conflated what a library is and where a library is. That's an important distinction that should not be glossed over like this.
I've been using Go professionally since 0.8 and in production since 1.0; this is correct.
Since day one we have forked every (external) package dependency in production code to our own github account and for all the constant complaining I hear, it has been very little heartache for us.
This has worked great, we periodically update our forks from upstream, once or twice a year need to fixup our code to match, run our unit tests an integration tests, do a little manual testing and call it good.
Vendoring through tarball dumps of GOPATH I can understand, but how do you deal with the dependencies of your dependencies when vendoring through forking?
Of our 40 or so external dependencies (huge project), only a handful themselves have dependencies we needed to also vendor. Its sounds painful, but in practice it hasn't been. We actually stopped using godep, we were getting no reward for the hassle and added complexity.
Unless there is a bug, or new feature we needed, we often just update this stuff when we update the Go release we are using.
My thoughts; KISS until more complexity is actually needed.
Wouldn't that involve changing the references in the mid-level to the leafs? Now you have to maintain changes to all the mid-level packages, sounds like not fun.
> The Go maintainers have conflated what a library is and where a library is. That's an important distinction that should not be glossed over like this.
I think this depends on whether GitHub treats URLs as just URLs, or more generally as URIs. Based on their documentation [0], they refer to them as URIs, which means they are intended to represent both Location and Identity [1]. The domain represents the "where", the repository path is the "what".
They should be able to change their URL schema relatively easily, by including the appropriate redirects - a mapping from the old schema to the new. Which is exactly the strategy they discuss in the HTTP Redirects section.
It's nothing Gradle-specific - as you say it's the Maven scheme and used by almost all JVM dependency managers. Note also there's a convention of using a domain you control in reverse order as the groupId (i.e. com.mycompany:myproject:1.0) which makes collisions extremely unlikely. Finally it's very easy in the maven ecosystem to run a "proxy repository" for your organization that indefinitely caches all the artifacts you depend on, thus ensuring that your builds will always be reproducible.
On the positive side, some of the complexity comes through enforcing some standards about what packages go into central - in particular you must have a properly declared license, developer contact information, and GPG sign your releases. Which are things other language ecosystems would do well to enforce.
The first time definitely is a drag, but I had to do it exactly once a few years ago. If I ever need to publish another library, it's trivial. Bintray isn't standard, which isn't the worst thing in the world but does become aggravating at times.
Re Bintray isn't standard: There is no standard, both Bintray and Maven Central are just internet repositories. JCenter is bigger, so if you define "standard" as "bigger one", Bintray is the way to do.
If by "standard" you meant "default", like Maven Central is the default in Maven, here I have some news for you as well.
Bintray is the default in Mac OS' Homebrew, Android Studio, Groovy's @Grab, and first class citizen in Gradle, Ivy and SBT.
That's my biggest peeve with Go. Well second biggest after hushed tone - generics. I really really wish there was something like a Gemfile or Rust's Cargo or Clojure's Meiningen, something that's not...whatever it is that we have today, which is technically nothing.
I can kind of understand the Go devs' POV which is that basically at Google all source code vendored under one giant tree, but that's just not how not-Google companies operate.
Rust is looking really attractive to me lately, as soon as I figure out lifetimes and the borrow checker completely....
The Go maintainers have conflated what a library is and where a library is. That's an important distinction that should not be glossed over like this.