Go build looks for the import package (go mod is enabled in version 1.14)


Today, I was looking at a program code and found that grpc was used in it. The directory structure of the program is like this

onlineClean Package name main
structs.go Package name proto
rpcClient Package name main

There is such code in rpccleint / test.go

import (

	pb "onlineClean/proto"



At that time, I felt a little strange. Can I compile the reference to onlineclean / proto in rpcclient?

So I tried it and executed go build (go version is 1.14) under rpccleint. I found that it can be compiled successfully.

I was thinking,What is the process of go build looking for the import package? How did it find the onlineclean / proto package

Obviously, go build here should start from the upper directory of rpcclient to find onlineclean / proto. Why does it find it from the upper directory rather than the current directory?

After searching the Internet, the online article says:

When we introduce a third party, it will find it in three local areas
1. Goroot path
2. Gopath path
3. Search under the vendor directory in the original directory

It didn’t mention that they would find it from the superior directory.

I checked the goroot and gopath variables (go env goroot and go env gopath) and found that none of them contained the onlineclean or.. / directory

I feel that the information on the Internet may not be complete, or the information on the Internet is too old for 1.14

Later, by chance, I found that if I copied rpcclient to other directories (side by side with onlineclean), I couldn’t compile. Compilation prompt “go: cannot find main module; see ‘go help modules'”

Then, I compared the difference between go env in onlineclean / rpcclient and rpcclient directories, and found that the main difference is the gomod environment variable:

In onlineclean / rpcclient, set gomod = D: \ HT \ software department \ data quality control platform \ code \ Huawei cloud \ go \ onlineclean \ go.mod will be output

In rpcclient, this environment variable is not output.

So I guess that when I open go mod, I will look up go.mod when I open go build. After finding it, I use this go.mod for third-party package management. I checked the help document of go mod and confirmed my guess.

go helo go.mod

A module version is defined by a tree of source files, with a go.mod
file in its root. When the go command is run, it looks in the current
directory and then successive parent directories to find the go.mod
marking the root of the main (current) module.

When the go command runs, it will first find out whether the current directory has go.mod. If not, it will keep looking up until it finds go.mod, and use the directory where it finds go.mod as the root directory for third-party package reference.

Recommended Today

Parsing c + + STL container list is different from Python list

class template std::list preface 📄Content of this article:C++ STL list 📇 Column:C/C++ | Comprehensive understanding of C + + STL Standard Template Library 👤 Author URI :Bauhinia fish 📆 Creation time:2022-1-3 📟 Little tip: the article is very long and detailed. It is recommended to collect it first 🔙Return to directory (recommended Collection):Comprehensive understanding of […]