If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/tools/godep shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 8y ago

• 15 active contributors
• BSD-3-Clause licensed
• CI configured
• ⚠ Stale — last commit 8y ago
• ⚠ Single-maintainer risk — top contributor 85% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live tools/godep repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/tools/godep.

What it runs against: a local clone of tools/godep — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in tools/godep | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2977 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of tools/godep. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/tools/godep.git
#   cd godep
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of tools/godep and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "tools/godep(\\.git)?\\b" \\
  && ok "origin remote is tools/godep" \\
  || miss "origin remote is not tools/godep (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "main.go" \\
  && ok "main.go" \\
  || miss "missing critical file: main.go"
test -f "save.go" \\
  && ok "save.go" \\
  || miss "missing critical file: save.go"
test -f "restore.go" \\
  && ok "restore.go" \\
  || miss "missing critical file: restore.go"
test -f "vcs.go" \\
  && ok "vcs.go" \\
  || miss "missing critical file: vcs.go"
test -f "dep.go" \\
  && ok "dep.go" \\
  || miss "missing critical file: dep.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2977 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2947d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/tools/godep"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Godep is a Go dependency management tool that fixes and reproduces exact versions of dependencies by saving them to a Godeps/Godeps.json manifest and copying source code into vendor/ or Godeps/_workspace/. It enables reproducible builds by locking dependency versions and managing import path rewrites for older Go versions that lack native vendor directory support. Single-package monolith: core logic lives in *.go files at the root (dep.go, save.go, restore.go, update.go, vcs.go, etc.), with vendored dependencies under vendor/github.com/kr/. The entry point is main.go. Tests are colocated (*_test.go). Configuration is read from Godeps/Godeps.json.

Go developers maintaining libraries or applications that need reproducible builds with pinned dependency versions, particularly those on Go 1.4–1.5 who need the -r rewrite flag. However, the project is now archived and the authors recommend migrating to golang/dep or other modern tools.

Archived and in maintenance-only mode. The project includes comprehensive test coverage (see *_test.go files), CI via Travis CI (.travis.yml), and a detailed Changelog and FAQ, indicating it was well-maintained. However, the README explicitly states 'Godep - Archived' and directs users to golang/dep, signaling the project is no longer actively developed—it's a historical reference for legacy Go projects.

High risk for new projects: Godep is officially deprecated and unsupported. The vendoring approach (copying source to Godeps/_workspace/) is obsolete since Go 1.6+ introduced native vendor directories. Migrating off Godep may be difficult for large legacy codebases with complex rewrite rules. The minimal vendor dependencies (only github.com/kr/ packages) suggest low external attack surface, but the tool itself will not receive security updates.

Nothing. The project is archived. No active development, PRs, or issues are being worked on. The last state preserved is the README pointing users to migrate to golang/dep.

git clone https://github.com/tools/godep.git
cd godep
go build -o godep ./
./godep save  # Example: save current dependencies

Daily commands:

go build -o godep ./
./godep save              # Save dependencies
./godep restore           # Restore from manifest
./godep go install ./...  # Run Go commands with fixed deps
GOPATH=$(godep path) go test ./...

• main.go — Entry point for the godep CLI tool; all commands are routed through here
• save.go — Core dependency resolution and saving logic; implements the primary workflow of capturing project dependencies
• restore.go — Restores dependencies from saved manifest; critical for reproducible builds
• vcs.go — Interfaces with version control systems (git, hg, svn, bzr); foundational for dependency tracking
• dep.go — Data structures representing dependencies and packages; core domain model used throughout
• godepfile.go — Reads/writes Godeps/Godeps.json manifest file; essential for persistence layer

• main.go (Go flag, os/exec) — Parse CLI arguments, dispatch to subcommands, manage overall tool lifecycle
  • Failure mode: Invalid command or argument parsing errors; unhandled subcommand panics
• save.go (Import graph analysis, VCS abstraction) — Analyze project imports, resolve dependencies, lock versions, populate Godeps.json
  • Failure mode: Unresolvable import paths, VCS query timeouts, circular dependency detection
• restore.go (VCS operations, file I/O) — Read Godeps.json and checkout dependencies into vendor/ at locked versions
  • Failure mode: Missing remote repositories, network failures, corrupted Godeps.json
• vcs.go (Subprocess execution, VCS CLIs) — Abstract version control operations (clone, update, query revision) across git/hg/svn/bzr
  • Failure mode: VCS tool not installed, authentication failures, malformed URLs
• pkg.go (Go AST parsing, os.Walk) — Parse Go source files, extract imports, build dependency graph
  • Failure mode: Syntax errors in Go files, symlink cycles, unreadable files
• godepfile.go (JSON marshaling, file I/O) — Serialize/deserialize Godeps.json manifest with dependency metadata
  • Failure mode: Schema version mismatch, corrupted JSON, permission denied on write

• User CLI → main.go — Subcommand and arguments
• main.go → save.go — Dispatch to save workflow
• save.go → pkg.go — Request import graph analysis
• pkg.go → dep.go — Return Dependency structs
• save → undefined — undefined

Add support for a new VCS system

1. Define a new VCS type struct implementing the Cmd interface in vcs.go (vcs.go)
2. Add detection logic to identify repositories of this type (vcs.go)
3. Implement revision discovery and checkout commands (vcs.go)
4. Write integration tests in vcs_test.go (vcs_test.go)

Add a new godep subcommand

1. Create a new file (e.g., newcmd.go) with a command handler function (main.go)
2. Register the command in the main function's command dispatcher (main.go)
3. Implement business logic using dep.go data structures and vcs.go for VCS operations (dep.go)
4. Add user-facing messages via msg.go for output formatting (msg.go)
5. Write tests in newcmd_test.go (dep_test.go)

Modify dependency resolution logic

1. Review the save.go workflow to understand current resolution strategy (save.go)
2. Adjust package scanning and import graph analysis in pkg.go (pkg.go)
3. Update version selection and locking in the save workflow (save.go)
4. Ensure Godeps.json serialization reflects changes via godepfile.go (godepfile.go)
5. Add tests in save_test.go (save_test.go)

• Go 1.4+ — godep is a Go tool designed to run on the Go toolchain it manages; targets Go 1.4 and newer for standard workspace compatibility
• Vendoring (vendor/ directory) — Reproduces dependencies by storing exact source code versions; precedes Go modules and enables deterministic builds
• JSON manifest (Godeps/Godeps.json) — Language-agnostic format for serializing locked dependency graph with commit hashes and import paths
• VCS abstraction (git, hg, svn, bzr) — Decouples dependency resolution from specific version control; supports diverse project ecosystems

• Vendoring instead of centralized repository

  • Why: Ensures dependencies are always available without external network calls during build
  • Consequence: Large repository sizes and potential duplication across projects; superseded by Go modules

• Lock entire dependency tree with specific commit hashes

  • Why: Guarantees reproducible builds by eliminating version negotiation at build time
  • Consequence: No automatic security updates; requires explicit godep update to pull in patches

• VCS-agnostic dependency discovery via import path introspection

  • Why: Supports projects using different VCS backends transparently
  • Consequence: Complex VCS detection logic; slower than centralized package registry

• Does not support Go modules (go.mod/go.sum); godep targets the GOPATH-based workspace model
• Does not perform semantic versioning constraint solving; only locks exact revisions
• Does not publish packages; strictly a dependency management and reproducible build tool
• Does not handle private dependency authentication beyond VCS-level credentials
• Does not provide central registry; relies on import paths resolving to VCS repositories

1. Rewrite mode is Go-version-specific: the -r flag only applies to Go < 1.6; for 1.6+ the native vendor/ directory is used, which can cause subtle import path mismatches if you mix old and new Go versions. 2. VCS detection is environment-dependent: if git, hg, svn, or bzr binaries are not in $PATH, version detection silently fails. 3. Test files are excluded by default: use -t flag to include *_test.go and testdata directories in vendor. 4. No lock-file atomicity: concurrent godep operations can corrupt Godeps.json if not serialized. 5. Import rewrite is fragile: rewriting import paths can break if packages use reflection or dynamic imports (not statically parseable).

• Vendor directory — Core to Godep's approach: dependencies are copied into a local vendor/ or Godeps/_workspace/ so builds don't depend on external network or upstream changes
• Import path rewriting — The deprecated -r flag automatically rewrites imports like import "foo" to import "myproject/Godeps/_workspace/src/foo" to ensure reproducible builds on Go < 1.6
• VCS version pinning — Godep pins dependencies to exact VCS commit hashes (e.g., Git SHA-1) by querying the actual repository, ensuring bit-for-bit reproducible builds
• Static import analysis — Godep parses import statements in .go files (excluding _test.go unless -t is set) to discover transitive dependencies; breaks on dynamic imports or reflection
• Manifest-based reproducibility — The Godeps.json file acts as a lock file, capturing exact versions and allowing godep restore to recreate the same dependency tree on any machine
• Workspace-local GOPATH — Godep sets $GOPATH to a project-specific workspace (output of godep path) to isolate dependencies and avoid global Go package pollution

• golang/dep — Official successor to Godep; the Godep team explicitly recommends migrating to dep for Go 1.5+
• golang/go — Go core; native vendor/ support was added in Go 1.6, making Godep's manual vendoring obsolete
• go-modules/go-modules.github.io — Go Modules became the official standard (Go 1.11+); replaces both Godep and dep
• kardianos/govendor — Contemporary alternative to Godep (2015–2016) with similar save/restore semantics
• Masterminds/glide — YAML-based dependency manager (2014–2019) that competed with Godep and dep for mindshare

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for vcs.go with mocked VCS operations

The vcs.go file handles critical version control system interactions (git, hg, bzr, svn) but vcs_test.go appears minimal. Given that godep's core functionality depends on reliable VCS operations, adding tests for different VCS types, error scenarios, and edge cases (missing VCS tools, malformed repos, network failures) would significantly improve reliability and catch regressions early.

• [ ] Examine vcs.go and vcs_test.go to identify untested functions and code paths
• [ ] Create mock VCS implementations or use interfaces to test without actual git/hg/bzr/svn binaries
• [ ] Add tests for: repo detection, tag/branch resolution, revision fetching, and error handling for each VCS type
• [ ] Add tests for edge cases: empty repos, missing VCS tools, network timeouts, and malformed repository URLs
• [ ] Ensure test coverage exceeds 80% for vcs.go

Add integration tests for save.go and restore.go workflows

The save.go and restore.go files implement the core godep workflows (saving and restoring dependencies), but the existing save_test.go and restore.go lack comprehensive integration tests. These should verify the end-to-end workflow: modifying dependencies, saving them to Godeps/Godeps.json, and restoring them correctly. This is critical since these operations directly affect user projects.

• [ ] Review save.go, restore.go, save_test.go, and restore_test.go to identify integration gaps
• [ ] Create temporary test Go workspaces with mock packages and dependencies
• [ ] Add integration tests that: save dependencies to Godeps.json, verify the JSON structure, modify dependencies, and restore them
• [ ] Test error scenarios: corrupted Godeps.json, missing dependencies, version conflicts
• [ ] Verify that the Godeps.json format remains compatible across save/restore cycles

Create GitHub Actions workflow to replace .travis.yml and test against multiple Go versions

The project uses .travis.yml for CI but modern Go projects should use GitHub Actions for faster, more reliable testing. The current setup doesn't explicitly show testing across multiple Go versions (1.4+). A GitHub Actions workflow would: test against Go 1.13-1.21+, validate on multiple OS platforms (Linux/macOS/Windows), and provide faster feedback to contributors.

• [ ] Create .github/workflows/test.yml with matrix testing for Go versions 1.13, 1.16, 1.19, 1.21
• [ ] Include runs-on matrix for ubuntu-latest, macos-latest, and windows-latest
• [ ] Add steps to: checkout code, setup Go, run go test ./..., and run go vet ./...
• [ ] Add step to verify vendored dependencies are consistent (go mod verify if applicable, or check Godeps/Godeps.json integrity)
• [ ] Update README.md to reference the new GitHub Actions badge instead of Travis CI

• Add test coverage for path.go (no corresponding path_test.go exists); test the FindVersionControl() function and edge cases like missing .git directories.
• Document the JSON schema in Godeps/Godeps.json with comments or an example; the Readme only shows usage, not the manifest structure for new contributors.
• Add a --dry-run flag to save.go that prints what would be vendored without modifying files; helpful for CI and safety.

The godep project has significant security concerns due to its archived and unmaintained status. The project explicitly directs users to migrate to alternative tools (dep, go modules). Key risks include: (1) use of an unmaintained dependency management tool that will not receive security updates, (2) vendored dependencies without modern verification mechanisms like go.mod/go.sum, (3) potentially outdated vendored packages with unpatched vulnerabilities, and (4) lack of active security maintenance. Users should migrate to Go modules or another actively maintained dependency management solution. The low security score reflects the inherent risk of using archived software for security-critical functions like dependency management.

• High · Archived Project - Unmaintained Dependency Management Tool — Readme.md, root project status. The godep project is explicitly marked as archived in the README with a notice directing users to use 'dep' or another tool instead. Using an unmaintained dependency management tool introduces security risks as vulnerabilities in dependencies will not be identified or patched through official channels. Fix: Migrate to an actively maintained dependency management tool such as 'dep', 'go modules' (built-in to Go 1.11+), or another modern Go dependency manager. Avoid using godep for new projects.
• Medium · Vendored Dependencies Without Lock File Verification — vendor/ directory structure. The project vendors dependencies (vendor/github.com/*) which appears to be an older Go dependency management pattern. There is no evidence of go.mod/go.sum files or checksum verification mechanisms visible in the structure. This increases the risk of supply chain attacks through compromised or modified vendored packages. Fix: Migrate to Go modules (go.mod/go.sum) which provide cryptographic verification of dependencies. Implement automated dependency vulnerability scanning with tools like 'go list -json -m all | nancy' or Dependabot. Verify checksums of all vendored packages.
• Medium · Outdated Vendored Dependencies from golang.org/x/tools — vendor/golang.org/x/tools/. The vendored golang.org/x/tools package appears to be pinned to an older version based on the project's archived status and lack of recent updates. This package may contain known vulnerabilities that have been patched in newer versions. Fix: If continuing to use this project, update vendored golang.org/x/tools to the latest version and audit for known CVEs. Consider using 'go mod tidy' and 'go get -u' with modern Go modules instead.
• Low · Missing Security Policy and Vulnerability Disclosure Process — Root directory, missing SECURITY.md. The repository does not appear to have a SECURITY.md file or documented vulnerability disclosure process. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Although the project is archived, add a SECURITY.md file directing users to report vulnerabilities to the maintainers or recommending they use maintained alternatives. Include a note about the archived status in security contexts.
• Low · Travis CI Configuration Without Modern Security Practices — .travis.yml. The .travis.yml configuration file is present but there is no evidence of automated security scanning, dependency checking, or vulnerability scanning in the CI pipeline. Fix: For any continued maintenance: implement automated dependency scanning (Dependabot, Snyk), SAST scanning, and vulnerability checks in the CI/CD pipeline. However, given the archived status, this is not a priority.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.