an external dependency and a package manager

Almost no real program is built entirely from code its authors wrote; it leans on other people's libraries — a JSON parser, a compression library, a web framework. An external dependency is any such piece of code your program needs but does not contain itself. A package manager is the tool that fetches those dependencies for you, installs them, and keeps track of their versions, so you do not have to hunt down and download each one by hand.

There are two broad flavors. A system package manager installs software for the whole machine and is run by the operating system's vendor — for example apt or dnf on Linux, or Homebrew on macOS — placing libraries and headers into shared system directories like /usr/lib and /usr/include. A language-level package manager works inside one programming language's ecosystem and is usually per-project: pip for Python, npm for JavaScript, and Cargo for Rust. You typically list the libraries you need in a project file, and the package manager reads that list, downloads the right versions, and makes them available to your build, often resolving the dependencies-of-your-dependencies automatically.

Why it matters: package managers are what make modern software development practical, turning 'find, download, build, and place ten libraries correctly' into one command. They also bring real risks: every dependency is code you now trust and must keep updated, version conflicts between dependencies can be painful, and a compromised or abandoned package becomes your problem too. Managing dependencies well — pinning versions, reviewing what you pull in — is a genuine part of systems work, not an afterthought.