search

golang-standards / project-layout

Standard Go Project Layout
Other
49.5k stars 5.15k forks source link

How in the hell do you use go modules with a complex app with multiple directories. #22

Open rhugga opened 5 years ago

rhugga commented 5 years ago

Every document or blog I have found are merely some simple helloworld crap with a single directory of source files and no external libraries.

I'm trying to convert my k8s controller to using go modules because getting our CI/CD system to work with dep is an ungodly nightmare.

Is there a good doc or example of someone using go modules with a complex directory structure of many go packages at multiple levels?

What a hair-pulling nightmare go dependencies are.

Clivern commented 5 years ago

Switching from dep to go modules is pretty easy @rhugga

first activate go mod if not active

$ export GO111MODULE=on

to switch from dep to go mod

$ go mod -init
$ go build ./...
$ rm -rf vendor Gopkg.* # look ma no hands
$ go list -m all

so go build ./... will fetch your dependencies and add them to go.mod and go.sum.

a nice wiki https://github.com/golang/go/wiki/Modules#daily-workflow

i already have two apps under my profile but i guess there is a lot of apps started to switch to go mod since dep not maintained anymore

williamh commented 5 years ago

I have wondered this as well. Where do go.mod and go.sum end up in a complex project?

frederikhors commented 5 years ago

@williamh still no answers?

vishal-yadav commented 5 years ago

@williamh typically go.mod and go.sum should be in the project root. kubernetes is one example.

sheikhusmanshakeel commented 4 years ago

This go module hell is real people!

dsoprea commented 4 years ago

I also have to anchor it with a .MODULE_ROOT file in the project root and have a GetModuleRootPath() function in the root package that knows how to search and find the root project path in order to find assets required for the unit-tests. Need to set a variable for it in Travis CI config. Have been unable to find any other way (since all of the projects flatten into executables and there is only a limited concept of a tree at the end).

thediveo commented 4 years ago

The Kubernetes Go client is a good example of the go module versioning hell: so far, the Kubernetes go client module maps all stable versions vx.y.z since 1.17.z onto v0.y.z, such as v0.17.0. Until go module versioning starts working in the Kubernetes client, I personally consider this versioning concept to be unready for real-world consumption and only a non-proof of concept.

And that's probably the reason for the mass of rather useless trivial blog posts that just repeat one after another the same useless examples (there is a nice German proverb fitting perfectly the blogosphere: "albeit everything has been said, it hasn't yet been said by everybody").