Feature request: Add native uv support and configuration

[JonZeolla]

Describe your idea/feature/enhancement

I wish the AWS Lambda Builders would support native uv usage instead of using uv export to facilitate dependency management (as designed here).

I know that experimental uv support was just added (related: #756 and #818). It mirrors the workaround I've been using for a while, but lacks certain capabilities that I need (and also have workarounds for).

Additional Details

It would be nice to be able to pass certain variables or arguments in order to use specific uv features, like described below

1. I noticed that the uv export doesn't include a --no-dev, which bloats the final artifact:

aws-lambda-builders/aws_lambda_builders/workflows/python_uv/packager.py

Lines 326 to 338 in ed7d955

	export_args = [
	"export",
	"--format",
	"requirements.txt",
	"--no-emit-project", # Don't include the project itself, only dependencies
	"--no-hashes", # Skip hashes for cleaner output (optional)
	"--output-file",
	temp_requirements,
	# We want to specify the version because `uv export` might default to using a different one
	# This is important for dependencies that use different versions depending on python version
	"--python",
	python_version,
	]

This seems to be in conflict with one statement from the design document:

aws-lambda-builders/aws_lambda_builders/workflows/python_uv/DESIGN.md

Line 26 in 051c6ef

5. **Package size optimization**: Lambda has deployment package size limits, requiring efficient dependency packaging

2. Currently, --no-hashes is hard coded, but in my environment I do require hashes in my pyproject.toml. This causes an issue because my [tool.uv.pip] config leaks into the builder subprocess, causing a conflict.

I'm not sure what phase things are currently in, given this is deployed, but still experimental, but I did note the following:

aws-lambda-builders/aws_lambda_builders/workflows/python_uv/DESIGN.md

Lines 311 to 329 in 051c6ef

	### Implementation Phases
	#### Phase 1: Core Infrastructure
	1. Basic workflow and action classes
	2. UV binary detection and validation
	3. Simple requirements.txt support
	4. Basic error handling
	#### Phase 2: Advanced Features
	1. pyproject.toml support
	2. Lock file handling
	3. Advanced configuration options
	4. Performance optimizations
	#### Phase 3: Production Readiness
	1. Comprehensive testing
	2. Error message improvements
	3. Documentation and examples
	4. Performance benchmarking

Which mentions "Advanced configuration options", and so it may be planned, future work to add support for --no-dev, etc.

3. It would be very useful to be able to natively mount a local package into the final build artifact. I already support this in my flow which wraps aws-lambda-builder/sam but I'd rather it be supported natively

I had Opus 4.6 do a write-up of some of the details/issues it had migrating from my current workaround to the new experimental approach, which may be helpful. I'm doing this with the sam cli.

Details

  Upstream Issues in aws-lambda-builders UV Workflow

  All bugs are in the experimental PythonUvBuilder workflow (aws-lambda-builders, shipped with SAM CLI >= 1.155.2). The
   relevant code lives in aws_lambda_builders/workflows/python_uv/.

  Bug 1: Dev dependencies included in build artifact

  File: packager.py, _build_from_lock_file() ~line 326-338

  Problem: The uv export command is missing --no-dev. All dependencies from [dependency-groups] dev in pyproject.toml
  are exported and installed into the Lambda artifact.

  Impact: Build artifact balloons from ~144M to ~408M (in our case), including pytest, pyright, cfn-lint, coverage,
  etc. Exceeds Lambda's 250MB unzipped size limit.

  Expected: uv export should include --no-dev to exclude development dependencies from production builds.

  Current code:
  export_args = [
      "export",
      "--format", "requirements.txt",
      "--no-emit-project",
      "--no-hashes",
      "--output-file", temp_requirements,
      "--python", python_version,
  ]

  Fix: Add "--no-dev" to export_args.

  ---
  Bug 2: --cached mode fails with CopyDependenciesAction

  File: workflow.py, _setup_build_actions() ~line 142-151

  Problem: When --cached is used (i.e. dependencies_dir is set), deps are installed to .aws-sam/deps/<uuid>/ but the
  CopyDependenciesAction is constructed with swapped semantics. It tries to os.listdir(artifact_dir)
  (.aws-sam/build/ExampleFunction) which doesn't exist yet — the deps are in destination_dir (.aws-sam/deps/).

  Error: [Errno 2] No such file or directory: '.aws-sam/build/ExampleFunction'

  Current code:
  CopyDependenciesAction(
      source_dir=source_dir,
      artifact_dir=artifacts_dir,          # .aws-sam/build/ExampleFunction (empty)
      destination_dir=self.dependencies_dir, # .aws-sam/deps/... (has deps)
  )

  The DependencyManager.yield_source_dest() does os.listdir(self._artifact_dir) then copies FROM artifact_dir TO
  dest_dir — which is backwards. Deps are in dependencies_dir but it tries to read from artifacts_dir.

  Impact: Every sam build with --cached fails for the UV workflow. Without --cached, builds always re-download deps.

  ---
  Bug 3: [tool.uv.pip] config leaks into builder subprocess

  File: packager.py, _build_from_lock_file() ~line 345-353

  Problem: The uv pip install command runs with cwd=project_dir, which makes uv read [tool.uv.pip] settings from the
  project's pyproject.toml. If the project has require-hashes = true (common security practice), but the builder
  exported with --no-hashes, uv pip install fails because it requires hashes that aren't present.

  Error: error: In --require-hashes mode, all requirements must have a hash, but none were provided for: aenum==3.1.16

  Root cause: The builder explicitly exports with --no-hashes (line 331) but doesn't account for the project's
  [tool.uv.pip] config overriding the install behavior. The uv pip install inherits the project's pyproject.toml
  settings since it runs from the project directory.

  Possible fixes:
  - Pass --no-verify-hashes to the uv pip install command
  - Run uv pip install with UV_NO_VERIFY_HASHES=true in the subprocess env
  - Export WITH hashes instead of --no-hashes (then the require-hashes config is satisfied)
  - Run uv pip install from a temp dir without pyproject.toml context

  ---
  Our Workarounds

  ┌────────────────────────┬───────────────────────────────────────────────────────────────────────────┐
  │          Bug           │                                Workaround                                 │
  ├────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
  │ Bug 1 (dev deps)       │ Generate our own uv export --no-dev requirements file, pass as --manifest │
  ├────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
  │ Bug 2 (--cached)       │ Don't use --cached flag                                                   │
  ├────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
  │ Bug 3 (require-hashes) │ Removed generate-hashes/require-hashes from pyproject.toml [tool.uv.pip]  │
  └────────────────────────┴───────────────────────────────────────────────────────────────────────────┘

  Bugs 1 and 2 are worked around by the same mechanism: since we generate our own requirements-*.txt via uv export
  --no-dev --no-hashes --frozen --no-emit-project, the lambda-builders use the _build_from_requirements path (simple uv
   pip install -r) instead of the buggy _build_from_lock_file path. This also avoids the --cached
  CopyDependenciesAction issue since we don't use --cached.

[sriram-mv]

Right thanks the issue! Yes the plan was to get the bare minimum necessary to get this out and then followed by a series of fixes that will remove paper cuts and frankly make it a joy to use. What you have said so far makes sense and we can implement that in phases.