Go Operations TO DELETE: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Internal=
=Internal=


* [[Go#Subjects|Go]]
* [[Go Engineering]]


=Subjects=
=Subjects=


* [[Go Concepts - Runtime#Environment_Variables|Environment Variables]]
* [[Go Concepts - Runtime#Environment_Variables|Environment Variables]]
* [[Go Commands|Commands]]


=Remote Imports=


Go has build in support for fetching source code from remote repositories.
=Sharing Code=


The import path can be used by Go tooling to determine where the code is on the network.
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.


For an import statement similar to:
=Dependency Management=
 
<pre>
import "github.com/something/somethingelse"
</pre>
 
<tt>go build</tt> will first search the local directories listed in GOPATH. If the package is found, the search stops. However, if using <tt>go get</tt>, the package (and its dependencies) is recursively fetched and placed in GOPATH.
 
=Portability=
 
=Debugging=
 
* https://golang.org/doc/gdb
 
=TODO=


<font color=red>
<font color=red>
NOMBP2:bakm ovidiu$ go help get
usage: go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages]


Get downloads and installs the packages named by the import paths,
* godep by Keith Rarick
along with their dependencies.
* vendor by Daniel Theophanes
* gopkg.in Gustavo Niemeyer


The -d flag instructs get to stop after downloading the packages; that is,
==Vendoring==
it instructs get not to install the packages.


The -f flag, valid only when -u is set, forces get -u not to verify that
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.
each package has been checked out from the source control repository
implied by its import path. This can be useful if the source is a local fork
of the original.


The -fix flag instructs get to run the fix tool on the downloaded packages
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.
before resolving dependencies or building the code.


The -insecure flag permits fetching from repositories and resolving
==<tt>gb</tt>==
custom domains using insecure schemes such as HTTP. Use with caution.


The -t flag instructs get to also download the packages required to build
<tt>gb</tt> does not wrap Go tooling, nor GOPATH
the tests for the specified packages.


The -u flag instructs get to use the network to update the named packages
<tt>gb</tt> replaces the workspace metaphor with a project-based approach.
and their dependencies.  By default, get uses the network to check out
missing packages but does not use it to look for updates to existing packages.


Get also accepts build flags to control the installation. See 'go help build'.
No need for import path rewriting.


When checking out a new package, get creates the target directory
http://getgb.io
GOPATH/src/<import-path>. If the GOPATH contains multiple entries,
get uses the first one. See 'go help gopath'.


When checking out or updating a package, get looks for a branch or tag
Go in Action page 75.
that matches the locally installed version of Go. The most important
</font>
rule is that if the local installation is running version "go1", get
searches for a branch or tag named "go1". If no such version exists it
retrieves the most recent version of the package.


Unless vendoring support is disabled (see 'go help gopath'),
=Debugging=
when go get checks out or updates a Git repository,
it also updates any git submodules referenced by the repository.


Get never checks out or updates code stored in vendor directories.
* https://golang.org/doc/gdb
 
* http://thornydev.blogspot.com/2014/01/debugging-go-golang-programs-with-gdb.html
For more about specifying packages, see 'go help packages'.
** https://github.com/derekparker/delve
 
** https://github.com/mailgun/godebug
For more about how 'go get' finds source code to
download, see 'go help importpath'.
 
See also: go build, go install, go clean.
</font>

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.

http://getgb.io

Go in Action page 75.

Debugging

Retrieved from "https://kb.novaordis.com/index.php?title=Go_Operations_TO_DELETE&oldid=105285"