Comment by corresation | Hacker News Reader

Comment by corresation | Hacker News Reader

Parent Full thread

Articles like this -- even if they have errors or arguable non-best-practices -- should be recommended because they drive conversation. Thus far one of the most unfortunate things I've noticed about the Go community (and this is seen even in discussions about Go on here) is a silence that results from a fear of doing things wrong. That improves no one.

The 'go list' command will tell you the dependencies for an application.

Does it? I thought it simply showed every package in the application, not differentiating what is yours and what is not. If I am correct, in no way does it solve the problem that they were trying to address.

This is not the recommended practice.

They specifically note that it isn't the recommended practice, but that it was a compromise to make a more easily reproducible structure. It is absolutely odd -- from a traditional developer perspective -- how the structure of a go application works when there are many dependencies, and I'm not sure what is the recommended practice for actually source controlling that (though we know how individual packages should be managed).

Go files matching the build tags are compiled into the resulting binary

Can you describe what you means? Such as

go build github.com/mypackage?

I've built several solutions with Go now and remain sure that much of what I'm doing is wrong, despite trying to find the relevant information.

> Articles like this -- even if they have errors or arguable non-best-practices -- should be recommended because they drive conversation.

I disagree. You could use the same argument to admit any old troll. As someone who's often critical of Go, I found the quality of TFA to be too low to be worthwhile. It gets a lot of things wrong and in my opinion breezes past many of the real problems.

More importantly, with new languages people are very quick to sling whatever FUD they can regurgitate against languages they've decided they don't want eating up the mindshare they'd rather some other language had.

> > The 'go list' command will tell you the dependencies for an application.

> Does it? I thought it simply showed every package in the application, not differentiating what is yours and what is not.

How is that not telling you the dependencies for an application? And differentiating yours from others ought to be trivial if you use the recommended directory structure with the path under /src corresponding to repository locations.

Many real applications consist of tens to hundreds of packages, tens to hundreds which might be in development in the application, and tens to hundreds which might be dependencies.

I fail to see how following the recommended directory structure (which is assumed) helps that, beyond that you can then correlate with a separate list of "things that are mine".

In a Visual Studio project, just to bring up a comparative example, I have my solution and projects. And then, elsewhere, I have nuget dependencies. There is absolutely no question which is which (nor is there any confusion on how to source control the whole, including that the dependencies include nothing more than pointers to their location/version). In my go project there are hundreds of seeming equals.

> I fail to see how following the recommended directory structure (which is assumed) helps that, beyond that you can then correlate with a separate list of "things that are mine".

If you are following the recommended directory structure, you don't need to "correlate" to "a list" of things that are yours, as all of your things will be under a path that corresponds to your remote repository, while external dependencies will be under paths that correspond to other remote repositories.

> In a Visual Studio project, just to bring up a comparative example, I have my solution and projects. And then, elsewhere, I have nuget dependencies.

In Go, you have the solutions and packages under (e.g.)

  /src/github.com/corresation/

And then, elswhere, you have dependencies that aren't yours.

The issues with package versioning and dependency management are well known and frequently discussed in the Go community. This article does not cover new ground in that discussion.

To list the dependencies for the application github.com/user/myapp, run the command:

    go list -f '{{.Deps}}' github.com/user/myapp

The command

   go build github.com/mypackage

builds github.com/mypackage and its dependencies. If github.com/mypackage is a command (a package with name 'main'), then the resulting binary is written to the current working directory. If github.com/mypackage is not a command, then you probably want

    go install github.com/mypackage

This command builds and installs the package.

> The issues with package versioning and dependency management are well known and frequently discussed in the Go community.

Is there a good place to see the current status of that discussion, or is it just spread across the mailing list?

Nathan Youngman's document is a good summary. https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8...

There are many threads on the mail list. There was probably one this week :).

Reply on news.ycombinator.com