Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: followup for activation doc #74

Merged
merged 3 commits into from
Nov 13, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 22 additions & 3 deletions docs/concepts/activation.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ which puts you into a subshell with everything configured:

```bash
$ flox activate
flox [myenv] $ # Now I can use my packages
flox [myenv] $ # Now you can use your packages
```

One of the core features that makes Flox so attractive for development is that
Expand All @@ -53,10 +53,10 @@ environment rather than from elsewhere on your system.

## Three different ways to activate

I mentioned above that there are three different ways to use an environment.
We mentioned above that there are three different ways to use an environment.

### Subshell
I've already mentioned the first method,
We've already mentioned the first method,
which is to put you into a subshell.
When you activate this way your existing shell is paused and you're put into a
new one configured by Flox.
Expand Down Expand Up @@ -299,6 +299,25 @@ If you edit your manifest and activate in a new shell,
the whole activation process is run again and subsequent activations will
attach to this new version of the environment.

## Development vs. runtime mode

In addition to the different ways to use an activation,
there are two different "modes" to activate in:
development mode and runtime mode.

The default mode at the moment is development mode.
In development mode a package and all of its development dependencies are made
available.
As the name implies, this is useful at development time.
However, this may causes unexpected failures when layering environments or
when activating an environment system-wide.

For these reasons we also provide "runtime" mode,
which simply puts the requested packages in `PATH`
(and makes their `man` pages available).
This behavior is more in line with what you would expect from a system-wide
package manager like `apt`, `yum`, or `brew`.

## Conclusion

As you can see, there's a lot going on under the hood,
Expand Down