Question
I used go get <package> to download a Go package before realizing that I should set GOPATH first. Because of that, the package was installed into my default Go workspace, and I want to keep my Go installation clean and separate standard Go files from third-party packages.
How can I remove packages that were previously installed with go get?
Short Answer
By the end of this page, you will understand what go get used to install, where Go stores downloaded source code and compiled binaries, and how to safely remove packages from your Go workspace. You will also learn the difference between removing source code, cached modules, and installed executables, plus how this differs between older GOPATH workflows and modern Go modules.
Concept
In Go, go get has historically been used to download and install packages. The important part is that Go does not usually install third-party code into the Go compiler itself. Instead, it places files in specific workspace locations.
The exact behavior depends on which Go workflow you are using:
- Older GOPATH mode: packages are downloaded into your
GOPATH/src, compiled package files may appear underGOPATH/pkg, and executables may be placed inGOPATH/bin. - Modern module mode: dependencies are usually stored in the module cache, typically under
GOPATH/pkg/mod, and command-line tools may still install binaries intoGOPATH/binorGOBIN.
This matters because removing a package means removing it from the correct location:
- Remove the source or module files if you no longer want the downloaded package.
- Remove the binary executable if
go getorgo installinstalled a command. - Sometimes you may also want to clean Go's build or module cache.
A common beginner misunderstanding is thinking that go get modifies the core Go installation under GOROOT. Normally, third-party packages belong in your workspace or module cache, not in the standard library directory.
So the real question is not "How do I uninstall Go itself?" but rather "Which Go-managed files did this package create, and which of those do I want to remove?"
Mental Model
Think of Go's package system like a workshop with separate storage areas:
GOROOTis the factory equipment. You usually do not touch it.GOPATH/srcor the module cache is the storage shelf for downloaded parts.GOPATH/binis the tool rack where runnable tools are placed.pkgand cache folders are the temporary workbench outputs.
If you downloaded the wrong tool, you do not throw away the whole workshop. You remove:
- the stored parts,
- the built tool,
- and maybe the temporary scraps.
That is how removing packages installed by go get works in practice.
Syntax and Examples
Check your Go paths
Before deleting anything, inspect where Go is storing files:
go env GOPATH
go env GOROOT
go env GOBIN
This helps you avoid deleting files from the wrong place.
Typical old GOPATH locations
If you ran:
go get github.com/user/tool
Go may have created files in these locations:
$GOPATH/src/github.com/user/tool
$GOPATH/pkg/... # compiled package files
$GOPATH/bin/tool # executable, if the package builds a command
To remove them manually:
rm -rf "$GOPATH/src/github.com/user/tool"
rm -f "$GOPATH/bin/tool"
You can also clear compiled package data with:
go clean -i github.com/user/tool
Modern module-related cleanup
If the package was downloaded into the module cache, you can clean unused downloaded modules with:
go clean -modcache
Be careful: this removes the entire module cache, not just one package.
Step by Step Execution
Example
Suppose you ran:
go get github.com/rakyll/hey
Now you want to remove it.
Step 1: Find your workspace
Run:
go env GOPATH
Assume it returns:
/home/alex/go
Step 2: Check whether a binary was installed
Look in:
/home/alex/go/bin
If you see a file named hey, remove it:
rm -f /home/alex/go/bin/hey
Step 3: Remove the downloaded source or package files
In older GOPATH mode, the source code may be here:
/home/alex/go/src/github.com/rakyll/hey
Remove it:
rm -rf /home/alex/go/src/github.com/rakyll/hey
Step 4: Remove compiled artifacts if needed
Run:
Real World Use Cases
Developers remove Go packages for several practical reasons:
- Cleaning a mistaken install: you installed a package before setting
GOPATHorGOBINcorrectly. - Removing old CLI tools: a tool was installed globally and you no longer use it.
- Resetting a broken environment: cached modules or compiled artifacts are causing confusing behavior.
- Keeping development environments reproducible: you want dependencies defined in
go.mod, not installed ad hoc. - Freeing disk space: the module cache can become large over time.
Examples:
- A developer accidentally installs a CLI tool into the default workspace and wants it removed.
- A CI machine needs a clean module cache before rebuilding dependencies.
- A team standardizes on
go install module@versionand removes older binaries installed withgo get. - A local machine has stale package data after switching Go versions.
Real Codebase Usage
In real Go projects, developers usually avoid manually installing library dependencies globally. Instead, they use these patterns:
Module-managed dependencies
Inside a project with go.mod, dependencies are tracked in files rather than manually managed in GOPATH:
go mod tidy
This removes unused dependencies from go.mod and go.sum, though it does not directly delete all cached module files.
Installing tools explicitly
Modern Go commonly uses:
go install example.com/cmd/tool@latest
This makes it clearer that you are installing a binary tool, not adding a library dependency to a project.
Environment inspection and guard checks
Developers often verify paths before deleting anything:
go env GOPATH GOBIN GOROOT
This acts like a guard clause for shell operations: check first, then delete.
Cleaning caches during troubleshooting
Common cleanup commands include:
go clean -cache
go clean -modcache
go clean -testcache
These are often used when builds behave unexpectedly.
Common Mistakes
1. Confusing GOROOT with GOPATH
A very common mistake is assuming third-party packages are installed into the Go standard library.
GOROOT= where Go itself is installedGOPATH= your workspace for user-downloaded packages in older workflows
Do not delete random directories from GOROOT unless you are intentionally uninstalling or repairing Go itself.
2. Deleting the wrong thing
Broken approach:
rm -rf /usr/local/go
This removes the Go installation, not just one downloaded package.
Safer approach:
go env GOPATH
rm -rf "$GOPATH/src/github.com/user/package"
3. Forgetting about binaries
A package may be gone from source storage, but its executable may still remain in bin.
Example:
rm -rf "/src/github.com/user/tool"
Comparisons
Related cleanup targets
| What you want to remove | Typical location | Best approach |
|---|---|---|
| Downloaded source in old GOPATH mode | GOPATH/src/... | Delete the package directory manually |
| Installed command binary | GOPATH/bin or GOBIN | Delete the executable file |
| Compiled package artifacts | GOPATH/pkg/... | go clean -i <package> |
| Module cache | GOPATH/pkg/mod | go clean -modcache |
| Build cache | Go build cache directory | go clean -cache |
Cheat Sheet
Quick reference
Check paths
go env GOPATH GOROOT GOBIN
Old GOPATH cleanup
Remove downloaded source:
rm -rf "$GOPATH/src/github.com/user/package"
Remove installed binary:
rm -f "$GOPATH/bin/package"
Remove compiled artifacts:
go clean -i github.com/user/package
Module/cache cleanup
Remove build cache:
go clean -cache
Remove test cache:
go clean -testcache
Remove module cache:
go clean -modcache
Important rules
- Third-party packages are usually not part of
GOROOT.
FAQ
How do I uninstall a Go package installed with go get?
Usually by deleting the downloaded package directory from your workspace and removing any installed binary from GOPATH/bin or GOBIN.
Does go get install packages into GOROOT?
Normally, no. Third-party packages are typically stored in GOPATH or the module cache, not inside the core Go installation.
How do I remove an installed Go command-line tool?
Delete its executable from $(go env GOPATH)/bin or from GOBIN if that variable is set.
What does go clean -modcache do?
It removes the entire downloaded module cache. Use it when you want a full dependency cache reset, not just one package removed.
What is the difference between removing a package and removing a binary?
Removing a package deletes source or cached dependency files. Removing a binary deletes the runnable executable. Sometimes you need to do both.
Should I delete files from GOROOT to clean up third-party packages?
No. Deleting files from GOROOT can damage your Go installation. Check GOPATH and first.
Mini Project
Description
Create a small shell-based cleanup checklist for Go tools and packages. The purpose is to practice identifying where Go stores downloaded packages, installed binaries, and cache data. This mirrors a real development task: cleaning up an accidental install without damaging the main Go setup.
Goal
Build and test a simple cleanup workflow that finds a Go-installed tool and removes the correct files safely.
Requirements
- Print the values of
GOPATH,GOROOT, andGOBIN. - Check whether a chosen tool exists in the binary directory.
- Remove the tool binary if it exists.
- Show how to remove the package source directory in old GOPATH mode.
- Print a final message confirming what was removed.
Keep learning
Related questions
Check if a Value Exists in a Slice in Go
Learn how to check whether a value exists in a slice in Go, and why Go has no Python-style `in` operator for arrays or slices.
Concatenating Slices in Go with append
Learn how to concatenate two slices in Go using append and the ... operator, with examples, pitfalls, and practical usage.
Convert String to Integer in Go: Idiomatic Parsing with strconv.Atoi
Learn the idiomatic way to convert a string to an int in Go using strconv.Atoi, with examples, errors, and common mistakes.