Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Feature request: Add native uv support and configuration

Aperta
#839 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
build-system

Direzione di ricerca

Inizia da aws_lambda_builders/workflows/python_uv/DESIGN.md ed esamina packager.py e workflow.py, che l’issue identifica come pertinenti per le opzioni di esportazione, la configurazione dell’installazione e la copia delle dipendenze memorizzate nella cache. Confronta la configurazione avanzata documentata con le esigenze riportate; il lavoro dovrebbe considerarsi completato quando la configurazione uv supportata e il comportamento dei pacchetti locali sono definiti e gli errori di build riportati sono stati risolti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

stage/needs-triage type/feature
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: https://github.com/aws/aws-lambda-builders/pull/756 and https://github.com/aws/aws-lambda-builders/issues/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:

https://github.com/aws/aws-lambda-builders/blob/ed7d955598e4f8974f9baba25cf1600176aa0054/aws_lambda_builders/workflows/python_uv/packager.py#L326-L338

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

https://github.com/aws/aws-lambda-builders/blob/051c6ef2fd0079190c758f1622af7a68e48eb723/aws_lambda_builders/workflows/python_uv/DESIGN.md?plain=1#L26

  1. 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:

https://github.com/aws/aws-lambda-builders/blob/051c6ef2fd0079190c758f1622af7a68e48eb723/aws_lambda_builders/workflows/python_uv/DESIGN.md?plain=1#L311-L329

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

  1. 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.
Lingua principale
Python
Stelle
381
Fork
162
Merge medio
1g 1h
PR unite (30g)
2

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aws/aws-lambda-builders

Tutte le issue di aws/aws-lambda-builders

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.