Hacker News Reader

Comment by twblalock | Hacker News Reader

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.

View on HN

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?

right? Forking changes the URL of a project, so are they updating the code?

I wish the go get tool would download to the vendor folder when using GO15VENDOREXPERIMENT

It does kick the can down the road, but it kicks it pretty far.

I'm not the parent but your question is completely valid -- trying to get dependencies of dependencies sends us down a very deep rabbit hole.

This is usually where dynamic linking and shrinkwrapping[1]/vendoring[2] start entering serious discussions.

[1] http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-mur...

[2] https://github.com/tools/godep

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.

> My thoughts; KISS until more complexity is actually needed.

Well, isn't that exactly what this artice is about…?

Wouldn't you just follow that through to the leaves?

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.

(edit) Formatting

[0] : https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

[1] : https://developer.github.com/v3/#http-redirects

All URLs are URIs.

Not true in practice.

Java does this pretty well, at least if you use Gradle, I think. You specify the location of the repository in the

  repositories { ... }

block and then specify (with maven naming scheme)

  dependencies { compile "group:name:version" }

where group might be something like org.apache, name might be apache-commons and version might be 2.5.

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.

the only aweful thing is deploying to the central repository

why? I have used sonatype and it's pretty much log in, promote to production.

It's a very painful process to get set up - no doubt it's easy after the first time. I've ultimately found it easier to go via bintray: http://blog.bintray.com/2014/02/11/bintray-as-pain-free-gate... .

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.

To be clear the point of the guide I linked is that you can publish to bintray and have them sync it into maven central.

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.

as soon as you are in, yes. but as a startup you need to waiiiiiiit

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

Reply on news.ycombinator.com