Installed a package via go get, but can't delete it? Full breakdown

Online Python Trainer for Beginners

Learn Python easily without overwhelming theory. Solve practical tasks with automatic checking, get hints in Russian, and write code directly in your browser — no installation required.

Start Course

"I installed a package, but I can't delete it!" — a familiar story?

\n\n

You're just starting to learn Go, you find a cool library on GitHub, you type go get github.com/example/package — and it works! But time passes, the project changes, and you realize: this package is no longer needed. You look for the go remove or go uninstall command, but... it simply doesn't exist.

\n\n

Welcome to the world of Go, where deleting packages is not a button, but a little adventure. In this article, we'll figure out where packages end up after go get, how to properly "evict" them, and why Go is designed this way. Spoiler: after reading this, you'll stop being afraid of clutter in your system and learn to keep your projects clean.

\n\n

How go get works: a brief primer

\n\n

Before deleting, let's understand exactly where the package goes. In Go (before version 1.16, but this knowledge is still relevant), the go get command downloaded the package source code into two directories:

\n\n
    \n
  • $GOPATH/src — the package source files (as if you had cloned the repository);
  • \n
  • $GOPATH/pkg — compiled object files (.a).
  • \n
\n\n

If you are using Go modules (and since version 1.16 this is the default mode), then go get works differently: it adds the dependency to go.mod and downloads the module to the cache ($GOPATH/pkg/mod).

\n\n

The problem is that Go has no built-in "delete package" command. The language developers believe that if you no longer need a package, simply don't import it in your code. It sounds logical, but what if you want to free up space or tidy things up?

\n\n

Method #1: go clean -i (for old projects without modules)

\n\n

In the past (before the era of modules), there was the go clean -i command. It deleted the compiled package files from $GOPATH/pkg. But it did not touch the source files. That is, you only deleted the binary artifacts, but the code itself remained in src.

\n\n
# Delete the compiled package files\ngo clean -i github.com/example/package\n\n# The source files are still here:\nls $GOPATH/src/github.com/example/package
\n\n

In practice, this was inconvenient. Therefore, in modern versions of Go (starting from 1.12), go clean -i is deprecated. If you run go clean -i now, Go will simply ignore the -i flag and execute a regular go clean (deleting object files in the current project).

\n\n

Method #2: Manual deletion from GOPATH (for veterans)

\n\n

If you are still working without modules (or just want to clean up old clutter), you'll have to do it manually. Here's the full recipe:

\n\n
    \n
  1. Find where your $GOPATH is located:
  2. \n
\n\n
go env GOPATH
\n\n

Usually it's /home/user/go or C:\\Users\\user\\go.

\n\n
    \n
  1. Delete the source files:
  2. \n
\n\n
rm -rf $GOPATH/src/github.com/example/package
\n\n
    \n
  1. Delete the compiled files (if they exist):
  2. \n
\n\n
rm -rf $GOPATH/pkg/linux_amd64/github.com/example/package.a
\n\n
\n

Important: The path to the .a file depends on your OS and architecture. linux_amd64 is a typical example. You can find the exact path via go list -m, but it's easier to just delete the entire package folder in pkg.

\n
\n\n

This method works, but it's messy. You risk accidentally deleting something important. Plus, if the package was used in other projects, they will break.

\n\n

Method #3: The modern approach — go mod tidy

\n\n

If you are using Go modules (and you should be using them if you started learning in 2024), then everything is much more elegant. When you stop importing a package in your code, it automatically stops being

Blogs

Book Recommendations