using vendoring to override standard library

548 views
Skip to first unread message

Alex Zylman

unread,
Aug 17, 2015, 6:39:32 PM8/17/15
to golang-nuts
Microsoft maintains a fork of crypto/tls that supports TLS renegotiation for Azure (background: https://github.com/Azure/azure-sdk-for-go/issues/90). For this to work, they also needed to fork net/http to import their forked crypto/tls. I noticed today that, in go 1.5, vendored imports are resolved before standard library imports, so if you had "vendor/crypto/tls", anything that referred to "crypto/tls" would point to your vendored code. This could be a much easier way of maintaining a fork like this. However, I couldn't find where the import resolution order was documented, so I'm not sure if this is behavior that I can depend on if I needed to do something similar.

Anyone know?

Dave Cheney

unread,
Aug 17, 2015, 6:46:30 PM8/17/15
to golang-nuts
I don't think that will work, $GOROOT always comes before any other path in the package lookup logic -- imagine the chaos I could cause if I included the path vendor/runtime in my repository.

Fwiw, at Canonical we had to for the net/http package for our azure client library, launchpad.net/gwacl

Thanks

Dave

Alex Zylman

unread,
Aug 17, 2015, 6:53:11 PM8/17/15
to golang-nuts
I tested this and that doesn't appear to be the case - if I make a folder "vendor/net/http", any import of "net/http" refers to my vendored package and NOT to the standard library. Here's a gist: https://gist.github.com/azylman/305ad6172dd884aaaed4

Alex Zylman

unread,
Aug 17, 2015, 7:01:07 PM8/17/15
to golang-nuts
Looking into this a little bit more, I think that the behavior depends which file is doing the importing. It seems like when my code imports "net/http", it gets the vendored version, but if I import something in GOROOT that imports "net/http", that gets the version in GOROOT.

This is maybe something I should file a bug about?

Benjamin Bytheway

unread,
Aug 17, 2015, 8:57:59 PM8/17/15
to golang-nuts
I had to fork http and tls as well, to work around the negative serial number issue https://github.com/golang/go/issues/8265.  I ended up bringing the code into my own project and rewriting all the import statements in the two paths.  It works, but it is not easy to maintain.

It would be really nice if there were better ways of forking/overriding the standard libraries that weren't so messy.

-Ben Bytheway
Reply all
Reply to author
Forward
0 new messages