Managed vs Project environments

flox offers two different kinds of environments: managed environments and project environments. In general, managed environments are most useful for creating a set of tools that can be shared using the flox command. Project environments are most useful for developing a single project that is tracked in git.

In more detail, managed environments:

• are identified by name and are managed by flox
• are modified with flox commands like install and remove
• are shared with flox push and flox pull
• are entered with flox activate
• can bring in executables, but can't bring in libraries, like shared objects (e.g. libssl) or language specific packages (e.g. Python requests)

Project environments:

• are stored in a user-managed git repository
• are modified with any editor (like any other file in the repository)
• are tracked in source control (like any other file in the repository)
• are entered with flox develop
• can bring in both executables and libraries

Common features

Managed and project environments share certain features given that both are "environments."

Environments are self-contained collections of packages for which all runtime dependencies are provided by flox independently of your system.

Unlike most package managers flox is system-agnostic and can be used alongside other native operating system package managers (e.g. apt, dnf, brew, etc.). flox environments run in an isolated manner; no system files are touched. When packages are installed they are added into a collection of packages called an "environment" rather than into common system paths such as /usr/bin where collisions with the operating system are possible.

This requires environments to be entered before they can be used. Conceptually this is similar to the way Python virtual environments work, where the current shell PATH variable is prefixed with the paths which define the packages available to that shell.