Skip to content

Clarifying locking for included environments #355

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.

Sign up for GitHub

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

Open
mkenigs wants to merge 1 commit into
base: main
Choose a base branch
from
+5 −2
Open

Clarifying locking for included environments #355

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
7 changes: 5 additions & 2 deletions docs/concepts/composition.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

@zmitchell zmitchell Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In order for changes to be pulled in, the included environment must have a lockfile corresponding to the latest changes to the manifest.
In order for changes to be pulled in, the manifest and lockfile of the the included environment must be in sync with one another (it's possible for them to get out of sync if you edit `manifest.toml` with your editor rather than `flox edit`).

Suggestion: this reads a little smoother to me

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.
Copy link
Contributor Author

@mkenigs mkenigs Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% sold this is the right place to make the change. Can't decide if it's overexplaining the concept in the wrong place or not

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.