tools/godep

★ 5,515GoAudience · developerComplexity · 2/5Setup · easy

Mindmap

mindmap
  root((godep))
    What it did
      Lock dependency versions
      Vendor folder copy
      Wrapper go commands
    Key commands
      godep save
      godep restore
      godep go test
    How it worked
      Godeps.json file
      Exact commit IDs
      Diff-friendly format
    Status
      Archived project
      Migrate to Go modules
      No new features

mindmap root((godep)) What it did Lock dependency versions Vendor folder copy Wrapper go commands Key commands godep save godep restore godep go test How it worked Godeps.json file Exact commit IDs Diff-friendly format Status Archived project Migrate to Go modules No new features

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Migrate an old Go project that still uses godep to modern Go modules by understanding what the Godeps.json file records.

USE CASE 2

Use godep restore to reproduce an exact historical build of a legacy Go project that hasn't been migrated yet.

USE CASE 3

Read the Godeps/Godeps.json file to audit which library versions a project depended on at a specific point in time.

Tech stack

Getting it running

Difficulty · easy Time to first run · 30min

Project is archived and no longer maintained, migrate to Go modules instead of starting new projects with godep.

License information is not mentioned in the explanation.

In plain English

Godep is an archived command-line tool for Go programmers that helped ensure software projects always built with exactly the same versions of their dependencies. A dependency in this context means any outside code library that a project relies on. Without a tool like this, two developers could run the same project and end up using different library versions, causing hard-to-trace bugs. When you ran godep save, the tool would scan your project, record the exact version of every outside library in a file called Godeps/Godeps.json, and copy those library files into a vendor/ folder inside your project. After that, anyone who cloned your project could run godep restore to install those same exact versions rather than whatever happened to be current at that moment. The tool also offered wrapper commands like godep go test and godep go install so you could keep running normal Go operations while godep made sure the right library versions were in place. For projects with multiple packages, running godep save ./... captured dependencies for all of them at once. This project is now archived. The Go community moved on to a newer official tool called dep, and the README explicitly directs users there. The godep repository is maintained only for existing users who have not yet migrated, with no new features planned. The file format godep used was simple JSON, recording the import path and the exact commit ID for each dependency. This made the dependency list readable and easy to diff in version control, so you could see exactly what changed between updates.

Copy-paste prompts

Prompt 1

I have a legacy Go project that uses godep and I need to migrate it to Go modules. Walk me through reading the Godeps.json file and converting each dependency to a go.mod entry.

Prompt 2

Explain what godep save ./... does step by step, what files it creates, where it puts the vendor copies, and how the Godeps.json records the exact commit IDs.

Prompt 3

I cloned an old Go project with a Godeps folder. How do I use godep restore to set up the exact dependencies it needs before building, and what can go wrong?

Prompt 4

Compare godep's vendor folder approach to modern Go modules and explain why the Go community moved away from godep to the official module system.

Prompt 5

I'm debugging a build failure in a project that uses godep. Show me how to read the Godeps/Godeps.json to find which version of a specific library was being used.

Open on GitHub → Explain another repo

← tools on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.