Skip to content

Support lock files for reproducible builds#12

Open
yzx9 wants to merge 1 commit into
apposed:mainfrom
yzx9:issue-33-lock-files
Open

Support lock files for reproducible builds#12
yzx9 wants to merge 1 commit into
apposed:mainfrom
yzx9:issue-33-lock-files

Conversation

@yzx9

@yzx9 yzx9 commented Jun 24, 2026

Copy link
Copy Markdown

PixiBuilder and UvBuilder now accept a lock file (uv.lock / pixi.lock) via new lockContent/lockFile/lockUrl methods that mirror the existing content/file/url declaration API and are defined once on the Builder interface. When a lock is supplied it is copied into the environment directory and the install runs in strict lock mode so the environment matches the committed lock (uv: --frozen; pixi: --frozen).

appose.json records a lockHash (SHA-256) of the lock content, so a change to the lock forces a rebuild through the normal isUpToDate() check. When no lock is supplied the lockHash key is omitted entirely, keeping appose.json byte-identical to before (no spurious rebuilds of existing environments) and never passing the strict flag.

DynamicBuilder forwards the lock to the detected pixi/uv delegate; MambaBuilder and SimpleBuilder override lockContent to throw UnsupportedOperationException. Note that pixi --frozen uses the lock as-is (the lock is authoritative) while uv --frozen fails fast on a stale lock; both make builds reproducible, and the tests assert the actual semantics of each tool.

closes apposed/appose#33

PixiBuilder and UvBuilder now accept a lock file (uv.lock / pixi.lock) via new lockContent/lockFile/lockUrl methods that mirror the existing content/file/url declaration API and are defined once on the Builder interface. When a lock is supplied it is copied into the environment directory and the install runs in strict lock mode so the environment matches the committed lock (uv: --frozen; pixi: --frozen).

appose.json records a lockHash (SHA-256) of the lock content, so a change to the lock forces a rebuild through the normal isUpToDate() check. When no lock is supplied the lockHash key is omitted entirely, keeping appose.json byte-identical to before (no spurious rebuilds of existing environments) and never passing the strict flag.

DynamicBuilder forwards the lock to the detected pixi/uv delegate; MambaBuilder and SimpleBuilder override lockContent to throw UnsupportedOperationException. Note that pixi --frozen uses the lock as-is (the lock is authoritative) while uv --frozen fails fast on a stale lock; both make builds reproducible, and the tests assert the actual semantics of each tool.
@ctrueden

Copy link
Copy Markdown
Member

@yzx9 Awesome! Thank you very much for this, and for all the work you've been doing on Appose. And apologies for the sluggishness of my responses and reviews. I'm not trying to ignore anything, just too busy as always. But Appose is a pretty high priority to me, so I will try to work on this soon.

@yzx9 yzx9 force-pushed the issue-33-lock-files branch from 07d0731 to dec7fe9 Compare June 25, 2026 02:17
@yzx9

yzx9 commented Jun 25, 2026

Copy link
Copy Markdown
Author

@ctrueden Thank you! No worries at all. I completely understand that open-source maintainers have a lot on their plate.

Thanks again for all your work on Appose. Please take your time with the review, and let me know if there’s anything I can improve or clarify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Builders ignore lock files, breaking reproducible builds

2 participants