News for hackers. Stuff that matters.

A comment on Looking at your program’s structure in Go 1.7. Parent comment

Re:Looking at your program’s structure in Go 1.7 by Spiritus on Tuesday August 16, 2016 @02:40AM (#12295912)
That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages.

We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying.

This is basically what all of them did:

    $ cd <folder with all their projects and code>
    $ git clone <repo>
    $ cd <repo>
    $ go build
And obviously it failed because it wasn't in a "src" folder (it was in a git, projects or code folder) nor had the $GOPATH environment variable set. But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get.

They just want to clone anywhere and run "go build".

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by mappu on Tuesday August 16, 2016 @05:27AM (#12296338)
Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`.

You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by stouset on Tuesday August 16, 2016 @12:29PM (#12298530)
Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by IshKebab on Tuesday August 16, 2016 @02:39PM (#12299564)
What if I don't use Makefiles, because I live in the 21st century?
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by tartley on Tuesday August 16, 2016 @03:35PM (#12299997)
That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented."

Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.

Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.

A good tool to solve a fundamental problem is still useful, no matter how old it is.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by icedchai on Wednesday August 17, 2016 @10:10PM (#12309973)
You could make a shell script instead.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by thewhitetulip on Tuesday August 16, 2016 @03:26AM (#12296036)
I agree on the point where it doesn't work well with mix languages. we can, however use `go get` rather than manually doing a git clone.

I understand it'd be a pain to have Go setup, but once it is setup, it is great, When I write Go programs

I do

`$ cd /go/src/github.com/thewhitetulip/Tasks` `$ Tasks go build -o tasks` `$ Tasks ./tasks`

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by stouset on Tuesday August 16, 2016 @12:31PM (#12298546)
How is this different from any other language where you "just" run `cd path/to/project; (make || rake || pants || cargo)`? This isn't special, and it's not something the go workspace makes possible.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by thewhitetulip on Tuesday August 16, 2016 @11:45PM (#12302397)
This is different because $GOPATH is a requirement of the language and in _other_ languages, you have to manually clone the repos in the correct root folder which you store all your code into.

Go allows you to do a go get reponame and it'll do the git clone stuff for you.

that is nothing short of amazing as far as code management is concerned. I love it.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by travisby on Tuesday August 16, 2016 @07:25AM (#12296688)
Take a look at [gvm](https://github.com/moovweb/gvm) I create (similar to a python virtualenv) a pkgset, and then use `linkthis` to link my current directory as a certain path in my gopath. You could do it yourself with symlinks, but I've been loving the tool for other things it provides, too (like easy access to new versions).

You can feel free to have any repo path you want :D

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by mseepgood on Tuesday August 16, 2016 @02:46AM (#12295928)
> But worst was probably the missing import path structure, i.e. "github.com/<company>/<repo>" that people simply just didn't get.

You obviously didn't vendor your dependencies in your project's vendor directory.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by CannisterFlux on Tuesday August 16, 2016 @03:19AM (#12296017)
I found vendor directories to be documented in a confusing way, so I'm not surprised.

https://golang.org/cmd/go/#hdr-Vendor_Directories

I think the example there is hard to follow. Perhaps with more standard package names, such as golang.org/x/net or a popular github.com package, instead of the made up foo, baz, quux and so on it would be easier to understand exactly what advantages vendoring gives you.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by twblalock on Tuesday August 16, 2016 @01:02PM (#12298836)
> You obviously didn't vendor your dependencies in your project's vendor directory.

You shouldn't have to!

A good dependency management system will produce reproducible builds via dependency versioning without any need to "vendor" anything.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by bigdubs on Tuesday August 16, 2016 @03:02AM (#12295980)
Vendoring doesn't work outside $GOPATH
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by mixedCase on Tuesday August 16, 2016 @11:58AM (#12298281)
Don't work outside $GOPATH. Set a temporary one if you want a completely isolated environment for one-off building purposes.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by stouset on Tuesday August 16, 2016 @12:32PM (#12298558)
Then what's even the point in the first place?
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by mixedCase on Tuesday August 16, 2016 @01:22PM (#12298969)
Development. Which is why I said "for one-off builds".
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by icholy on Tuesday August 16, 2016 @11:19AM (#12298009)
Why is this the case?
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by Spiritus on Tuesday August 16, 2016 @03:08AM (#12295990)
It didn't have any external dependencies, only multiple packages.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by 0xdeadbeefbabe on Tuesday August 16, 2016 @12:54PM (#12298770)
If you choose to vendor part of stdlib like http then boom diamond dependency problem approaches.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by fpoling on Tuesday August 16, 2016 @02:50PM (#12299662)
Even if one vendors the external dependencies, the code that uses them must still be on GOPATH or the compiler would not find them. This is at least with go 1.6.
[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by IshKebab on Tuesday August 16, 2016 @02:38PM (#12299560)
I agree. I think the real problem is that they are using environment variables for this. Environment variables just aren't user friendly, especially on Windows.

It would be better if Go just downloaded all `go get` packages to some default fixed directory (%appdata%/go or whatever), and then the code the people manually download/write could live anywhere.

[ Parent | on HN ]
Re:Looking at your program’s structure in Go 1.7 by thewhitetulip on Tuesday August 16, 2016 @11:47PM (#12302400)
On another note, I suggest you work around this limitation, you can write a benchmark in Go in the $GOPATH of your company or anything and then use `go install` to install it to the $PATH of your machine, so you can call the benchmark directly. This will separate the codebases.

Otherwise you can write the other language code in the $GOPATH itself.

[ Parent | on HN ]