From 80c02c264de2d09f96479ce020e24d7d555cf389 Mon Sep 17 00:00:00 2001 From: Matthew Kenigsberg Date: Mon, 27 Oct 2025 17:30:11 -0600 Subject: [PATCH] Clarifying locking for included environments A user asked for additional clarification of how locking of included environments works --- docs/concepts/composition.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/concepts/composition.md b/docs/concepts/composition.md index ea8eb9ed..5683a338 100644 --- a/docs/concepts/composition.md +++ b/docs/concepts/composition.md @@ -130,6 +130,9 @@ This can be surprising, so check the manifests of the included environments and It's reasonable to assume that the manifests of the included environments will change over time and at some point you will want to bring in the latest versions of those manifests. This is accomplished with the `flox include upgrade` command. -Running this command will check each of the included environments and determine if there were changes to their manifests. -If the changes to the manifest have been built by the included environment, then the new manifest will be included. +Running this command will check each of the included environments and check if the environments have changed. +In order for changes to be pulled in, the included environment must have a lockfile corresponding to the latest changes to the manifest. +For example, suppose an environment `my-go-project` includes a `go-tools` environment. +If the `manifest.toml` for `go-tools` is modified without using `flox edit`, then `flox include upgrade` for `my-go-project` won't be able use the changes to the `go-tools` manifest. +Using `flox edit` for `go-tools` would re-lock the environment using the latest manifest, and then `flox include upgrade` for `my-go-project` could pull in the changes. At this point the merge process runs again, a new merged manifest is produced, and the composed environment is rebuilt from the new merged manifest.