提示:由于水平有限,如发现有疑问或错误的地方请毫不客气的提出、讨论,我会在第一时间回复,感谢在先
Content from command : go help importpath
An import path (see 'go help packages') denotes(表示) a package stored in the local file system. In general,an import path denotes(表示) either a standard package (such
as "unicode/utf8") or a package found in one of the work spaces (For more details see: 'go help gopath').
Relative import paths
An import path beginning with ./ or ../ is called a relative path.
The toolchain supports relative import paths as a shortcut(快捷方式) in two ways.
First,a relative path can be used as a shorthand(速记) on the command line.
If you are working in the directory containing the code imported as
"unicode" and want to run the tests for "unicode/utf8",you can type
"go test ./utf8" instead of needing to specify the full path.
Similarly,in the reverse situation,"go test .." will test "unicode" from
the "unicode/utf8" directory. Relative patterns are also allowed,like
"go test ./..." to test all subdirectories. See 'go help packages' for details
on the pattern Syntax.
Second,if you are compiling a Go program not in a work space,
you can use a relative path in an import statement in that program
to refer to nearby code also not in a work space.
This makes it easy to experiment(实验) with small multipackage programs
outside of the usual work spaces,but such programs cannot be
installed with "go install" (there is no work space in which to install them),
so they are rebuilt from scratch(from scratch 白手起家;从头做起) each time they are built.
To avoid ambiguity,Go programs cannot use relative import paths
within a work space.
1.一般情况下,不能在work spackes 中使用相对路径; demo:
--ch2
--cte.go (package ch2 var Y = 4)
--main
-- main.go
package main
import (
"fmt"
"../../ch2" 注意这里要锁定到 ch2这个包,../ch2是不行的
)
func main(){
fmt.Printf(ch2.Y)
}
cd main and go run main.go (succed)
Remote import paths
Certain import paths also
describe how to obtain the source code for the package using
a revision(版本) control system.
A few common code hosting sites have special Syntax:
Bitbucket (Git,Mercurial)
import "bitbucket.org/user/project"
import "bitbucket.org/user/project/sub/directory"
GitHub (Git)
import "github.com/user/project"
import "github.com/user/project/sub/directory"
Launchpad (Bazaar)
import "launchpad.net/project"
import "launchpad.net/project/series"
import "launchpad.net/project/series/sub/directory"
import "launchpad.net/~user/project/branch"
import "launchpad.net/~user/project/branch/sub/directory"
IBM DevOps Services (Git)
import "hub.jazz.net/git/user/project"
import "hub.jazz.net/git/user/project/sub/directory"
For code hosted on other servers,import paths may either be qualified(受限于)
with the version control type,or the go tool can dynamically fetch
the import path over https/http and discover where the code resides
from a tag in the HTML.
To declare the code location,an import path of the form
repository.vcs/path
specifies the given repository,with or without the .vcs suffix(前缀),
using the named version control system,and then the path inside
that repository. The supported version control systems are:
Bazaar .bzr
Git .git
Mercurial .hg
Subversion .svn
For example,
import "example.org/user/foo.hg"
denotes the root directory of the Mercurial repository at
example.org/user/foo or foo.hg,and
import "example.org/repo.git/foo/bar"
denotes the foo/bar directory of the Git repository at
example.org/repo or repo.git.
When a version control system supports multiple protocols,
each is tried in turn when downloading. For example,a Git
download tries then git+ssh://.
By default,downloads are restricted to known secure protocols
(e.g. https,ssh). To override this setting for Git downloads,the
GIT_ALLOW_PROTOCOL environment variable can be set (For more details see:
'go help environment').
If the import path is not a known code hosting site and also lacks a
version control qualifier(修饰),the go tool attempts to fetch the import
over https/http and looks for a tag in the document's HTML
The meta tag has the form:
The import-prefix is the import path corresponding to the repository
root. It must be a prefix or an exact match of the package being
fetched with "go get". If it's not an exact match,another http
request is made at the prefix to verify the tags match.
The meta tag should appear as early in the file as possible.
In particular,it should appear before any raw JavaScript or CSS,
to avoid confusing the go command's restricted parser.
The vcs is one of "git","hg","svn",etc,
The repo-root is the root of the version control system
containing a scheme and not containing a .vcs qualifier(修饰).
For example,
import "example.org/pkg/foo"
will result in the following requests:
https://example.org/pkg/foo?go-get=1 (preferred)
http://example.org/pkg/foo?go-get=1 (fallback,only with -insecure)
If that page contains the meta tag
the go tool will verify that contains the
same Meta tag and then git clone into
GOPATH/src/example.org.
New downloaded packages are written to the first directory listed in the GOPATH
environment variable (For more details see: 'go help gopath').
The go command attempts to download the version of the
package appropriate for the Go release being used.
Run 'go help get' for more.
Import path checking
When the custom import path feature described above redirects to a
known code hosting site,each of the resulting packages has two possible
import paths,using the custom domain or the known hosting site.
A package statement is said to have an "import comment" if it is immediately
followed (before the next newline) by a comment of one of these two forms:
package math // import "path"
package math /* import "path" */
The go command will refuse to install a package with an import comment
unless it is being referred to by that import path. In this way,import comments
let package authors make sure the custom import path is used and not a
direct path to the underlying code hosting site.
Import path checking is disabled for code found within vendor trees.
This makes it possible to copy code into alternate locations in vendor trees
without needing to update import comments.
same meta tag and then git clone into
GOPATH/src/example.org.
New downloaded packages are written to the first directory listed in the GOPATH
environment variable (For more details see: 'go help gopath').
The go command attempts to download the version of the
package appropriate for the Go release being used.
Run 'go help get' for more.