Skip to content

fix: Fix uv.lock check for running uv export with --frozen#747

Open
richardowen wants to merge 1 commit into
terraform-aws-modules:masterfrom
richardowen:patch-1
Open

fix: Fix uv.lock check for running uv export with --frozen#747
richardowen wants to merge 1 commit into
terraform-aws-modules:masterfrom
richardowen:patch-1

Conversation

@richardowen

@richardowen richardowen commented Apr 30, 2026

Copy link
Copy Markdown

Description

The check for the uv.lock file is done while inside the temp directory, which only contains the pyproject.toml and uv.lock files. So the check always fails if the source_path is a directory, as the uv_lock_file variable set further up includes the directory path.

Motivation and Context

This change fixes the check so it finds the uv.lock file in the current (temp) directory if it exists, and therefore sets the --frozen option correctly.

Breaking Changes

None, unless users are relying on the behaviour that dependencies are being installed which don't match those defined in the uv.lock file. I.e. the behaviour of uv export without --frozen.

How Has This Been Tested?

I have tested this with the package_dir_uv example. I didn't need to modify the example; it is currently not working correctly (i.e. it doesn't pass --frozen even though a lock file is present in the fixture). With my change, --frozen is now passed in correctly.

The check for the uv.lock file is done while inside the temp directory, which only contains the pyproject.toml and uv.lock files. So the check always fails if the source_path is a directory, as the uv_lock_file variable set further up includes the original path.

This change fixes the check so it finds the uv.lock file in the current (temp) directory if it exists, and therefore sets the --frozen option correctly.
@richardowen richardowen changed the title Fix uv.lock check for running uv export with --frozen fix: Fix uv.lock check for running uv export with --frozen Apr 30, 2026
@github-actions

Copy link
Copy Markdown

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

@github-actions github-actions Bot added the stale label Jun 11, 2026
@richardowen

Copy link
Copy Markdown
Author

Not stale

@github-actions github-actions Bot removed the stale label Jun 12, 2026
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.

1 participant