Closed thoellrich closed 6 years ago
Yeah, I was trying to avoid -u, because that means go will always go out to the internet to try to download a new version, whereas go get will check if there's one installed and thus run much faster. But you're right, it's a possible problem. One thing I might consider doing is seeing if I can run hugo as a library, then I could vendor it at a specific revision and ensure that it was always using the right version.
Understand the aversion to use -u
for everybody if not necessary.
To be on the safe side, vendoring is probably the correct. And just to be complete: for the mage
build, there appears to be another path: git describe --abbrev=0 --tags
in $GOPATH/src/github.com/gohugoio/hugo
would tell you what release is present (if the dir exists) and you could have a minimum tag you support in gnorm.
I'm closing this issue, because I don't think it should appear as an "issue" here for gnorm
.
Going to look at supporting mysql unsigned int/bigint
now (because they fail).
https://github.com/gnormal/gnorm/blob/bc1de9a29a7341664ad1c9cdbd5af036d47e3caf/mage.go#L55
I had both hugo and statik at older versions in GOPATH.
mage build
would fail deep in the bowels of the hugo-build.go get -u
did the trick in my case.