# Introduction

Nix is a _purely functional package manager_.  This means that it
treats packages like values in a purely functional programming language
— packages are built by functions that don’t have
side-effects, and they never change after they have been built.  Nix
stores packages in the _Nix store_, usually the directory
`/nix/store`, where each package has its own unique subdirectory such
as

    /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/

where `b6gvzjyb2pg0…` is a unique identifier for the package that
captures all its dependencies (it’s a cryptographic hash of the
package’s build dependency graph).  This enables many powerful
features.

## Multiple versions

You can have multiple versions or variants of a package
installed at the same time.  This is especially important when
different applications have dependencies on different versions of the
same package — it prevents the “DLL hell”.  Because of the hashing
scheme, different versions of a package end up in different paths in
the Nix store, so they don’t interfere with each other.

An important consequence is that operations like upgrading or
uninstalling an application cannot break other applications, since
these operations never “destructively” update or delete files that are
used by other packages.

## Complete dependencies

Nix helps you make sure that package dependency specifications are
complete.  In general, when you’re making a package for a package
management system like RPM, you have to specify for each package what
its dependencies are, but there are no guarantees that this
specification is complete.  If you forget a dependency, then the
package will build and work correctly on _your_ machine if you have
the dependency installed, but not on the end user's machine if it's
not there.

Since Nix on the other hand doesn’t install packages in “global”
locations like `/usr/bin` but in package-specific directories, the
risk of incomplete dependencies is greatly reduced.  This is because
tools such as compilers don’t search in per-packages directories such
as `/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include`, so if a package
builds correctly on your system, this is because you specified the
dependency explicitly. This takes care of the build-time dependencies.

Once a package is built, runtime dependencies are found by scanning
binaries for the hash parts of Nix store paths (such as `r8vvq9kq…`).
This sounds risky, but it works extremely well.

## Multi-user support

Nix has multi-user support.  This means that non-privileged users can
securely install software.  Each user can have a different _profile_,
a set of packages in the Nix store that appear in the user’s `PATH`.
If a user installs a package that another user has already installed
previously, the package won’t be built or downloaded a second time.
At the same time, it is not possible for one user to inject a Trojan
horse into a package that might be used by another user.

## Atomic upgrades and rollbacks

Since package management operations never overwrite packages in the
Nix store but just add new versions in different paths, they are
_atomic_.  So during a package upgrade, there is no time window in
which the package has some files from the old version and some files
from the new version — which would be bad because a program might well
crash if it’s started during that period.

And since packages aren’t overwritten, the old versions are still
there after an upgrade.  This means that you can _roll back_ to the
old version:

```console
$ nix-env --upgrade --attr nixpkgs.some-package
$ nix-env --rollback
```

## Garbage collection

When you uninstall a package like this…

```console
$ nix-env --uninstall firefox
```

the package isn’t deleted from the system right away (after all, you