Click on the blue "Flying Snow Ruthless" above to follow me, set a star, and read the article as soon as possible
When a project becomes more and more complex, it must be split into multiple modules for code reuse and better multi-person collaborative development.
Suppose we already have two modules flysnow.org/util and flysnow.org/product , and the module flysnow.org/product depends on flysnow.org/util .
Now there is a requirement that these two modules need to be modified at the same time, so that the new methods of flysnow.org/util can be used by the module flysnow.org/product.
However, when colleague A adds a new method to the module flysnow.org/util, it will either be pushed to VCS for colleague B who is in charge of the module flysnow.org/product to use. This is the release scenario.
What if the module flysnow.org/util is not published? Then it can only be replaced by the replace command in go.mod, and the reference to the module flysnow.org/util is replaced with a local unreleased version, such as:
replace flysnow.org/util => /Users/flysnow/go/demo/utilI believe we have all encountered the above two situations, both of which have corresponding disadvantages, such as:
Publishing code that is not debugged or tested will affect other normal builds
When replacing, I forgot to change it back and submitted it to VCS, which affected other people's use
In order to solve the above problems, the Go team proposed the concept of workspace and released it in Go 1.18.
Go workspace is your workspace, it has nothing to do with multi-person collaboration, VCS, etc. To put it bluntly, it is a local directory that manages multiple go.mod modules through the go.work file.
To create a Go workspace is very simple, just use the following command:
mkdir workspace
cd workspace
go work init /Users/flysnow/go/demo/util /Users/flysnow/go/demo/productIn the above example, workspace is a workspace I created, which can be anywhere on your computer, and the name can also be chosen by yourself.
Then go work init is followed by two absolute paths of go.mod, separated by spaces, of course you can also use relative paths.
After running the above code, a go.work file will be generated in the workspace directory, and its content is as follows:
go 1.18
use (
/Users/flysnow/go/demo/product
/Users/flysnow/go/demo/util
)use is a directive in the go.work file to manage the included go.mod modules.
In addition to the use instruction, go.work also has a replace instruction, which is similar to the replace of go.mod. It is used to replace all the go.mod managed by the Go workspace with the specified path, and its priority is higher than that of go. The mod's replace should be high.
Now, the two modules we use are in the same workspace, so there is no need to modify the go.mod replace command of the module flysnow.org/product to complete the local dependencies.
At this time, in the workspace directory of the workspace, run the following command to verify.
➜ workspace go run flysnow.org/product
你好Because they are all in the same workspace, go can help you find the flysnow.org/util module that the module flysnow.org/product depends on.
If you just switch to the product directory and run the above command, you will only be prompted:
➜ product go run main.go
main.go:3:8: no required module provides package flysnow.org/util; to add it:
go get flysnow.org/utilNot only the example above that relies on upstream modules can use the Go workspace, but also if you have multiple modules in a code base, you just need to add them all to the Go workspace.
The go work command has a use that can add modules in the local directory to the workspace, as shown below:
go work use [path-to-your-module]The path in square brackets can be replaced with the local module path on your own computer.
Of course, you can also directly modify the go.work file, the effect is the same, no more examples here, you can try it yourself.
go.work is essentially a localized solution, because go.mod is placed in VCS and is closely related to the project, so we rarely modify it to achieve some Hack operations.
Now that you have go.work, it is much easier to handle, because it is a local thing, not in VCS, you can change it as you want, and it will not touch the go.mod of the managed module, so it will not affect other Collaborative developers, very secure.
—— Wonderful recommendation ——
GitHub launches AI-based code auto-completion tool Copilot
A simple Golang implementation of Socket5 Proxy
Go Team Presentation at GopherCon 2021: Introduction to Generics in Go 1.18
Go 1.18 is released, you can download it without going over the wall! ! !
Scan code attention
Share, like, watch is the biggest support