"I installed a package, but I can't delete it!" — a familiar story?
\n\nYou'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.
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.
How go get works: a brief primer
\n\nBefore 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
$GOPATH/src— the package source files (as if you had cloned the repository); \n $GOPATH/pkg— compiled object files (.a). \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).
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\nMethod #1: go clean -i (for old projects without modules)
\n\nIn 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.
# 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\nIn 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).
Method #2: Manual deletion from GOPATH (for veterans)
\n\nIf 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
- Find where your
$GOPATHis located: \n
go env GOPATH\n\nUsually it's /home/user/go or C:\\Users\\user\\go.
- \n
- Delete the source files: \n
rm -rf $GOPATH/src/github.com/example/package\n\n- \n
- Delete the compiled files (if they exist): \n
rm -rf $GOPATH/pkg/linux_amd64/github.com/example/package.a\n\n\n\n\nImportant: The path to the
\n.afile depends on your OS and architecture.linux_amd64is a typical example. You can find the exact path viago list -m, but it's easier to just delete the entire package folder inpkg.
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\nMethod #3: The modern approach — go mod tidy
\n\nIf 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