fix: changing package.build.config does not invalidate caches#5371
Merged
ruben-arts merged 7 commits intoprefix-dev:mainfrom Jan 21, 2026
Merged
Conversation
This fixes an issue where changes to `[package.build.config]` in pixi.toml (such as `noarch = true` to `noarch = false`) would not invalidate the metadata cache, causing the lock file to appear up-to-date when it should have been re-solved. The fix introduces a `ConfigurationHash` that captures changes to both the `configuration` and `target_configuration` fields from the build backend. This hash is now: - Computed when creating metadata via `call_conda_outputs` - Stored in `CachedCondaMetadata` - Checked during cache freshness verification in `verify_cache_freshness` When the configuration changes, the metadata cache is invalidated, triggering a re-query of the build backend and subsequent lock file update. Fixes prefix-dev#5309
Contributor
Hofer-Julian
left a comment
Hofer-Julian
left a comment
There was a problem hiding this comment.
Looks good. Would be great to have a test for this though
ruben-arts
approved these changes
Jan 20, 2026
Contributor
ruben-arts
left a comment
ruben-arts
left a comment
There was a problem hiding this comment.
Works as expected, added two small nitpicks.
Adds a test that verifies changing `[package.build.config]` correctly invalidates the metadata cache and causes the build backend to be re-queried. The test uses ObservableBackend to verify that: 1. The backend is called once for initial lock file generation 2. The backend is NOT called again when nothing changes (cache hit) 3. The backend IS called again when `[package.build.config]` changes 4. The backend is NOT called again after the cache is updated This tests the fix for issue prefix-dev#5309.
baszalmstra
force-pushed
the
claude/investigate-and-fix-issue-FhDyh
branch
from
e949513 to
7d2d168
Compare
Changed ConfigurationHash::compute to always return a hash value instead of Option<Self>. This simplifies the API and ensures consistent behavior whether configs are empty or not. Added Default impl for backward compatibility with existing cache files.
Extended test_build_config_change_invalidates_cache to verify that: 1. Starting with no [package.build.config] section works 2. Adding an empty [package.build.config] section does NOT invalidate the cache (empty config hashes the same as no config) 3. Adding actual config values DOES invalidate the cache 4. Changing config values also invalidates the cache
Contributor
Author
|
@ruben-arts Should work now! |
Contributor
diff --git a/examples/pixi-build/cpp-sdl/pixi.toml b/examples/pixi-build/cpp-sdl/pixi.toml
index 868ed770c..4a52af73c 100644
--- a/examples/pixi-build/cpp-sdl/pixi.toml
+++ b/examples/pixi-build/cpp-sdl/pixi.toml
@@ -32,6 +32,7 @@ channels = [
name = "pixi-build-cmake"
version = "0.3.*"
+[package.build.config]
[package.host-dependencies]
# This ensures that SDL2 is available at build time.This will still trigger a rebuild. |
Contributor
Author
|
@ruben-arts Are you sure you cleared the cache? There is a test that literally checks that. |
Contributor
Author
|
@ruben-arts I just tried it myself and it seems to work for me! |
Contributor
I did recheck with clean cache ( Maybe this reproducer helps: |
Replaced the single PackageBuildInputHash in CachedBuildSourceInfo with separate project_model_hash and configuration_hash fields. This aligns the build cache with the metadata cache structure, using the same hash types (ProjectModelHash and ConfigurationHash) for both caching systems. Removed PackageBuildInputHash and PackageBuildInputHashBuilder as they are no longer needed.
baszalmstra
force-pushed
the
claude/investigate-and-fix-issue-FhDyh
branch
from
481bfd1 to
2ff419c
Compare
Contributor
Author
|
@ruben-arts OKE! Should be good now. :) All caches now use the same mechanism for the configuration. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This fixes an issue where changes to
[package.build.config]in pixi.toml (such asnoarch = truetonoarch = false) would not invalidate the metadata cache, causing the lock file to appear up-to-date when it should have been re-solved.The fix introduces a
ConfigurationHashthat captures changes to both theconfigurationandtarget_configurationfields from the build backend. This hash is now:call_conda_outputsCachedCondaMetadataverify_cache_freshnessWhen the configuration changes, the metadata cache is invalidated, triggering a re-query of the build backend and subsequent lock file update.
Fixes #5309
How Has This Been Tested?
AI Disclosure
Tools: Claude Code Opus 4.5
Checklist:
schema/model.py.