Running go mod vendor updates my libraries - go

I'm trying to vendor my go-modules and am using go 1.11.5. However, when i run go mod vendor, it appears that under the hood go mod tidy is being called first. This updates my go libraries. Unfortunately, I am dependent on an older version of a certain library.
Is there any way I can vendor based on go.sum instead?
Any help much appreciated!

I think the problem I was having is that my go program specified version 1.2.3 of a specific library, but a dependency of my program pulled in version 1.2.4, resulting in a bump when I did a go vendor.
Hostile environment here! I had no idea ;). I will think twice before asking anything in the future.
Peace!

Related

List or update outdated Go packages with major version update

With go get -u it's possible to update all packages in a Go application that uses go.mod. However, there's a convention in Go that the package name gets updated for a major version when there are breaking changes.
For example "github.com/ahmetb/go-linq" changes in "github.com/ahmetb/go-linq/v2" after an update with breaking changes.
How can I detect if any of the packages I use updated their major version?
This has an open proposal that is on hold.
From that thread you may want to use gomajor and see if it works for you.

Issue with using a modified version of a Go dependency

So here is the situation:
I have a fork of go-ipfs. It depends on go-ipfs-config. I need to modify go-ipfs-config and make go-ipfs depend on my modified version.
I forked the go-ipfs-config made my changes and made sure to update the path to be that of my forked version as can be seen here. I confirmed that this still builds successfully by running go build
Then I updated go.mod in go-ipfs to use my modified version. I used the replace directive to signify this intention which can be seen here
This is where things gets absolutely bunkers and I am no longer sure what is going on.
When i do go mod tidy to fetch the dependency i get the following output:
go: finding module for package github.com/dadepo/go-ipfs-config
go: found github.com/dadepo/go-ipfs-config in github.com/dadepo/go-ipfs-config v0.5.3
The crazy thing is that v0.5.3 does not exist in github.com/dadepo/go-ipfs-config!
Also the following line get added to go.mod :
github.com/dadepo/go-ipfs-config v0.5.3 // indirect
Which can even be seen here
I have run commands like go clean -modcache and go clean -r etc but does not seem to fix things!
Does anybody know what I am doing wrong? And also how to achieve the goal of making my version of a project depend on another modified version of its dependency?
Ok, so this is as a result of me not being aware of couple of things going on in the Go lang toolchain.
Apparently https://proxy.golang.org is a thing! It is a service operated by google that caches modules. So If you made a release, deleted it, chances are that the version is already cached in https://proxy.golang.org. This was exactly what happened in my case. I had made a 0.5.3 release, deleted it, but it is not really gone as the Google cache already got a hold of it.
So in case you are seeing versions that should not exist. This should be the first place you check. This documentation link also sheds some more light on the proxy and how it can be tweaked.
I found this out based on the conversation I had on the issue I opened reporting this behaviour. If you are curious, you can check it out here.

Specifying to contributors what version of go to use in a go project

In node projects, package.json lets contributors know what version of node they can use to either consume or contribute to a specific project. Python uses venv to control the version used in collaborative development environments, and many other languages have similar constructs as well.
Does go have a standardized process that allows you to do something similar?
No, but Go has the 1 promise of compatibility - they try very hard not to break any extant software built on 1.x, even at the expense of leaving an ugly API or unwanted behaviour (though this is rare). This means you don't really have to worry about specifying which version of Go you use. Go 2 is not even on the horizon, so for the foreseeable future, you don't have to worry about this. There are a few new features, but most go users upgrade (because of the stable upgrade path).
https://golang.org/doc/go1compat
Re which dependencies you have, at present the only solution is to put your dependencies into a vendor folder, but I think you were asking about the language specifically.

Package management with go vendoring

How do you use go vendoring. It is written many places that 1.6 now include vendoring, but I can not find any documentation?
When use go get, I see no vendor folder?
I just need to be able to control packages like npm, apt etc.
As of 1.5 (with a flag) and 1.6 by default the go tools will look in the vendor folder for dependant packages before your GOPATH, for specifics see the design doc
But the go tools do not include tooling to populate that folder for you.
There are many tools that try to handle it for you, for example Godep, gvt and others.
You still need to use go get to get the packages into your GOPATH first.

How to improve Golang compilation speed?

I'm trying to find a way to make the compilation of a Go program faster. It is currently about 30 seconds, which makes it slow to work with the project.
When I run go build -v, I see that most of the time is spent compiling go-sqlite3 (which links to the C sqlite lib). However, since this lib never changes, I'm wondering if it's possible to prevent the build tool from recompiling this every time?
Try go install -a github.com/mattn/go-sqlite3 which will install the compiled-against-Go-1.3 package into your $GOPATH.
Right now, you likely have an older version installed under $GOPATH/pkg/ and therefore Go is recompiling it for every build.
This is likely due to you upgrading to go 1.3
I had to remove $GOPATH/pkg to get rid of old (incompatible) binaries
and then it was able to cache compilation results again
In Go 1.10 no need to run go install etc. Just use go build. The new version uses a build cache to determine which packages need to be re-compiled.
Check out: https://tip.golang.org/doc/go1.10

Resources