Getting Started with Go language--DEP

　　This article has seen a lot of maven content, more suitable for Java programmers to read, if your language is dependent on the management of the program and MAVEN is very different, may be in some places will not understand

A long time ago, the lack of the go language in terms of dependency solutions and management was criticized by many people. A lot of things can't be done by looking for a go get command. I don't know when it started, DEP, the official solution began to be promoted. From the description, not earlier than go 1.8, from the source of GitHub, at least open source will not be more than 1 years

The official introduction to DEP is "DEP was the official experiment, but not yet the official tool." However, "DEP is safe for production use." I do not actually use in practice, but also do a lot of experiments, can be found to be stable, and "well-known", in the future if there is a better dependency management program, nine out of ten is also the upper UI Shell Bar

There is, of course, a question in front of it: Does Jenkins seem to have no DEP plugin? That's just a handwritten script.

Before you look down, make sure you know two terms: we call this Github.com/apodemakeles/ugo project, a repository on GitHub, and a project that Github.com/apodemakeles/ugo /time This is called package, which is a Go Language pack under Project. Current project represents the item you are currently writing

　　Pre-knowledge points

First of all, you have to understand that the go to get the dependency package is done by the go Get command, by parsing the import statements in the code, to download the corresponding source code to $GOPATH/SRC, and then install, installed under $gopath/pkg. So if you want to correspond to the Java jar package that you downloaded in Maven, that actually equals the source code in go and a bunch of. a files. Description of Go get

But the problem with go get is that there is no version control, and the code you run today may not be the same as the code generated tomorrow on Jenkins.

Another problem is the feature of the go language, because all dependencies must have corresponding source code and. A files under $gopath, so different projects on the same machine cannot use different versions of the same dependency. Do you want GIT to checkout a different project when it's compiled?

So in Go 1.5 began the official introduction of the go vendor mechanism, simple point is in the original project directory with a vendor folder, the source code are "copied" to here, directory structure. All imports prefer to use the source code in vendor. This opening, a time for third parties to launch their own reliance on the solution, such as I have used the Govendor. Description of Go Vendor

　　DEP at a Glance

To use DEP, you first have to go to GitHub to download the DEP source code and compile the cost-effective executable file. Make sure your $gopath/bin is in your path so that you can perform the DEP command at the command line. See the GitHub and DEP official documentation for details.

Create a project casually, of course, under the $gopath, at this time do not write code, at least do not import remote dependencies, execute

DEP Init

You can see three more things under Project path, a vendor folder, this future to put current project's remote dependent source code, A gopkg.toml file, you can temporarily associate it with a pom file, or npm Package.json file and a Gopkg.lock file, what is it?

　　

Since the toml file is similar to Pom or package.json, follow the inside comment and try adding a dependency, like I did.

[[constraint]]   " Github.com/apodemakeles/ugo " "=0.1.0"    

It seems to mean that you need to download Ugo this project, and the limit version is 0.1.0, the following execution

DEP ensure

This directive is similar to Install,compile, that is, depending on the configuration content, download dependencies, compilation dependencies. The instructions were executed soon, but nothing happened? This is why I said "temporary" analogy to the Pom file, dep in combination with TOML and the import statements in the code, will really download, compile dependencies . Paste the following code into the project

Package Mainimport (    "fmt"    "Github.com/apodemakeles/ugo /time") Func main () {    fmt. Println (Utime. Nowunixts ())}

Re-executing DEP ensure, you'll see the source code in the vendor, and the lock file that doesn't know what it is:

# thisfileIs autogenerated, Donot edit; Changes may undone by the next'DEP ensure'. [[projects]] name="Github.com/apodemakeles/ugo"Packages= [" Time"] revision="96e9671d8beda19466b4296a8939ebfe26210683"version="v0.1.0"[Solve-Meta] Analyzer-name ="DEP"Analyzer-version =1Inputs-digest ="4b0b8768bb38a412e1bbfd9952fe578e6f5b1a7469e3f44e444d66ca0c7ffaf6"Solver-name ="GPS-CDCL"Solver-version =1

Now formally explain the toml file and the lock file:

The toml file records the constraints of current project dependency project, not what project should be, and which project is to see which package was import. This constraint is mainly reflected in whether to use the target project's version of a tag, or a branch, or a commit SHA1 (revision), later we will call its "type", These three can only choose one for a constraint. You can try to get rid of toml content, perform DEP ensure, still can download file to vendor, still modify lock file

In fact, in addition to constraint, there are several other constraints, more important required,ignored,override, the first two of this article will not focus on, override will be highlighted later. Description of the Toml file

Lock file is a tool generated, you should not manually edit , lock file packages corresponding to your import content, and revision (must have, and type irrelevant) and version is vendor the source of the true reflection. Description of the lock file

Notice that version says "v0.1.0"? This is the real tag on my github code, the constraint in the Toml file ignores the first letter V and pulls directly the code of Tag v0.1.0.

Next, change the version in Toml to "=0.1.1", assuming you need a feature of a later version of Ugo and need to upgrade dependencies. After you finish dep ensure you will find that the vendor has changed and the lock file has changed.

This is a brief introduction to DEP, and I suggest you look at the operating mechanism of DEP. It mentions the DEP ensure command, which can be analogous to the execution of a function: Toml and import are like the input of a function, after the first function resolving, the output is the lock file, which is passed as input to the second function vendoring, The output is the contents of the Vendor folder. This will help you understand, in this article does not relate to the situation, you can infer their own

　　A scenario for simulating maven

　　Here's what I fake, a real-world development workflow that's not validated

First, it's best to make sure your project uses the Semver standard-the semantic version standard, semver instructions, which specify the meaning, comparison, and some operators of the version number. It also stipulates that the initial version starts from 0.1.0 (see this surprise, our group blindfolded)

Then, understand what code you rely on and which version you need to use. If it's your own team's class library, follow the Semver standard and use Git's tag function to represent version, such as a v0.1.0 tag.

After that, make a new project according to go requirements, and take care of version control. Write the vendor/in the ignore. Here I have wondered if lock can also be ruled out? Actually, but the official document mentions the "commit" lock file.

DEP Init is performed in the project root directory. Generate these three things. If you can copy a copy of TOML, DEP Init does not have to be executed at all, as long as there are toml files, dep ensure can generate the other two completely.

After encoding, related to the remote dependency of the content, first imported in import, then select the corresponding version, modified in Toml, and then perform DEP ensure

If you need to upgrade during development, modify the Toml file, and then perform DEP ensure

After the CI tool has been pulled to the code, because of the toml file, the direct DEP ensure can be done, the end of the dependency is finally executed go build

So it looks like the whole world only this one command is necessary

Note that in my proposed scenario, the toml file should be written like this version= "0.1.0", do not 0.1.0 the previous plus equals number, why so, you first better understand the go DEP version rule

　　Version rules

Version rules here, to put it simply, the three-bit version number first is major, cross-major can be incompatible, the latter two bits are minor and patch, must be guaranteed to be backwards compatible within the same major range. Frankly, I used 1.2.1 version, now replaced with 1.2.2 or 1.3.1, must be no error, but 2.1.0 not (this is the rules of our architecture group)

In DEP, the =0.1.0 representative determines this version, ^0.1.0 represents >=0.1.0 and <1.0.0

[[constraint]]   " Github.com/apodemakeles/ugo " "0.1.0"    

This is equivalent to ^0.1.0, the default is generally the recommended solution, why recommend this? You can understand that if you follow the Semver specification, there is a certain backward compatibility across major, so even if you get to 0.1.1, 0.2.0, there is no error. But why not fix a coordinate like maven?

　

　　Transitive dependency

Suppose a relies on a function of B (A, A, project, jar, or DLL), we use A->B to indicate that if there is a->b->c, B is directly dependent on C, and A to C is the transitive dependency. If it happens to be a->b->c and a->c, but these two C is not a version, what happens?

In node. js, there is no such problem, there will be two C in the dependent folder, but for C#,java,go these languages, their common feature is that under current project, the final C will only have a real product on disk, (DLL, JAR, With the path of. A), this is where the problem of dependency conflict occurs

In the C # msbuild, pick a random C (I feel always choose the high version), build the DLL, but at run time, any DLL that uses C.dll will check that there is no version of C in the currently dependent version range, and if not, an error occurs at run time

In the Java maven, the "Shortest path" principle is used, at which point the A->c path is closer to the version of the POM with this path. But this leads to another problem, if the C version of this short path is relatively low, just B is going to use a higher version of C, because there is a new method that will go wrong at run time.

What about the DEP for go? If you write this in the toml file,

[[constraint]]   " github.com/apodemakeles/b "    "=xxx" [[constraint]] "github.com/     apodemakeles/c ""=0.1.1 "  

At this time regardless of b->c version than 0.1.1 High or low (B->c also written as version= "=x.x.x"), DEP is not allowed, will error, the reason is "has no overlap". If B->c and A->c in a major, then let go, directly write verion= "x.x.x"

That's why I recommend it without an equal sign.

But sometimes it's about deciding what to do with a particular version. You can use another constraint in toml override

[[constraint]]   " github.com/apodemakeles/b "    "=xxx" [[Override]] "github.com/     apodemakeles/c ""=0.1.1 "  

This enforces the use of 0.1.1 's version of C, but it is possible that the same situation above MAVEN requires your own responsibility

　　

　　Details of the fragmented

Up to here basically I think the important content is finished, toml and lock in a lot of content did not say, such as required,ignored, these things themselves look good. There are some DEP ensure parameters, such as-update,-add, I think we do not know better, can unify the use of norms, only with DEP ensure. And the authorities don't recommend branch or revision as version control.

• If you want a 0.0.1 version of Project, and the server has only 0.1.0 or more versions, it is not available even when using scopes such as ^,~. I guess it's because DEP took 0.1.0 as the most original version.
• DEP status to view current dependency information
• DEP ensure very slow.

　　

Getting Started with Go language--DEP