4 ms·

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

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.

dragonwriter 13y ago
> > 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.
- corresation 13y ago
  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.
  - dragonwriter 13y ago
    > 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.
BarkMore 13y ago
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.
- sanderjd 13y ago
  > 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?
  - BarkMore 13y ago
    Nathan Youngman's document is a good summary. https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8ZrKUPvUd3GMSA8cw8A4/edit https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8... There are many threads on the mail list. There was probably one this week :).
smosher 13y ago
> 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.

dragonwriter 13y ago

> > 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.

corresation 13y ago
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.
- dragonwriter 13y ago
  > 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.

BarkMore 13y ago

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.

sanderjd 13y ago
> 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?
- BarkMore 13y ago
  Nathan Youngman's document is a good summary. https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8ZrKUPvUd3GMSA8cw8A4/edit https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8... There are many threads on the mail list. There was probably one this week :).

smosher 13y ago

> 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.