Go Operations TO DELETE: Difference between revisions
No edit summary |
|||
| (27 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[Go | * [[Go Engineering]] | ||
=Subjects= | =Subjects= | ||
* [[Go Concepts - Runtime#Environment_Variables| | * [[Go Concepts - Runtime#Environment_Variables|Environment Variables]] | ||
= | |||
=Sharing Code= | |||
From "Go in Action" - to clarify: <font color=purple>The package should live at the root of the repository. When you're using <tt>go get</tt>, you specify the full path to the package that should be imported. This means that when you create a repository that you intend to share, the package name should be the repository name, and the package's source should be in the root of the repository's directory structure. A common mistake that new Go developers make is to create a <tt>code</tt> or <tt>src</tt> directory in their public repository. Doing so will make the package's public import longer. Instead, just put the package source files at the root of the public repository.</font> Page 72. | |||
=Dependency Management= | |||
<font color=red> | |||
* godep by Keith Rarick | |||
* vendor by Daniel Theophanes | |||
* gopkg.in Gustavo Niemeyer | |||
==Vendoring== | |||
Vendoring is a technique that involves copying the dependencies inside the project repository and then rewrite the import paths to reference those dependencies by providing the location inside the project itself. | |||
One benefit of vendoring and import path rewriting is that the project repository is still go-gettable. When go get is called against the project repo, the tooling can find each package and store the package exactly where it needs to be inside the project itself. | |||
==<tt>gb</tt>== | |||
<tt>gb</tt> does not wrap Go tooling, nor GOPATH | |||
<tt>gb</tt> replaces the workspace metaphor with a project-based approach. | |||
No need for import path rewriting. | |||
http://getgb.io | |||
Go in Action page 75. | |||
</font> | |||
=Debugging= | =Debugging= | ||
* https://golang.org/doc/gdb | * https://golang.org/doc/gdb | ||
* http://thornydev.blogspot.com/2014/01/debugging-go-golang-programs-with-gdb.html | |||
** https://github.com/derekparker/delve | |||
** https://github.com/mailgun/godebug | |||
Latest revision as of 20:31, 3 January 2024
Internal
Subjects
Sharing Code
From "Go in Action" - to clarify: The package should live at the root of the repository. When you're using go get, you specify the full path to the package that should be imported. This means that when you create a repository that you intend to share, the package name should be the repository name, and the package's source should be in the root of the repository's directory structure. A common mistake that new Go developers make is to create a code or src directory in their public repository. Doing so will make the package's public import longer. Instead, just put the package source files at the root of the public repository. Page 72.
Dependency Management
- godep by Keith Rarick
- vendor by Daniel Theophanes
- gopkg.in Gustavo Niemeyer
Vendoring
Vendoring is a technique that involves copying the dependencies inside the project repository and then rewrite the import paths to reference those dependencies by providing the location inside the project itself.
One benefit of vendoring and import path rewriting is that the project repository is still go-gettable. When go get is called against the project repo, the tooling can find each package and store the package exactly where it needs to be inside the project itself.
gb
gb does not wrap Go tooling, nor GOPATH
gb replaces the workspace metaphor with a project-based approach.
No need for import path rewriting.
Go in Action page 75.