Skip to content

feat: support uv workspace sources in direct_code_deploy #468

@dnorton

Description

@dnorton

Summary

agentcore launch (direct_code_deploy) does not resolve [tool.uv.sources] workspace dependencies when building the deployment package, causing ModuleNotFoundError at runtime for any package that lives in the same repo as a workspace member.

Current behavior

When a project uses a uv workspace to share a local library across agents, the pyproject.toml for each agent declares the dependency like this:

[project]
dependencies = ["shared-utils"]

[tool.uv.sources]
shared-utils = { workspace = true }

This works perfectly for local development (uv sync resolves the workspace member and installs it as an editable package). However, when agentcore launch runs, it builds dependencies.zip by executing:

uv pip install --target <tmp_dir> \
  --python-version 3.12 \
  --python-platform aarch64-manylinux2014 \
  --only-binary :all: \
  -r requirements.txt

This bare uv pip install call has no awareness of the workspace — [tool.uv.sources] is silently ignored. The local package is never installed, never bundled, and the agent fails at runtime with:

ModuleNotFoundError: No module named 'shared_utils'

Why the pyproject.toml fallback also fails

If requirements.txt is absent, agentcore falls back to pyproject.toml and runs uv pip compile pyproject.toml. This also fails:

error: Failed to parse entry: `shared-utils`
  Caused by: `shared-utils` references a workspace in `tool.uv.sources`
  but is not a workspace member

uv pip compile requires the package to be listed in the workspace root's [tool.uv.workspace].members. Agent subdirectories are typically not registered as workspace members, so this path is a dead end.

Root cause

agentcore launch treats the agent directory as self-contained. The existing expand_source_path_for_dependencies utility in bedrock_agentcore_starter_toolkit/utils/paths.py has the right idea — it expands the build context to the common root when a dependency is outside the source dir — but it is not wired up to handle workspace sources declared in [tool.uv.sources].

Expected behavior

When agentcore detects a [tool.uv.sources] workspace entry in pyproject.toml, it should:

  1. Resolve the workspace root (walk up directories until a pyproject.toml with [tool.uv.workspace] is found).
  2. Expand the build context to include the workspace package directory (consistent with what expand_source_path_for_dependencies already does for path deps).
  3. Pass the resolved path to uv pip compile / uv pip install so the local package is installed into dependencies.zip.

Alternatively, running uv pip compile with the workspace root as CWD (rather than the agent directory) would allow uv to resolve workspace members correctly.

Workaround

Until this is fixed, the only reliable workaround is to build a wheel manually before each deployment and reference it by relative path in requirements.txt:

# Build wheel (not committed to git)
uv build --package shared-utils --out-dir packages/shared-utils/dist/

# requirements.txt in each agent:
../../../../packages/shared-utils/dist/shared_utils-0.1.0-py3-none-any.whl

This is fragile, requires a manual pre-deploy step, and defeats the purpose of having a workspace.

Environment

  • bedrock-agentcore-starter-toolkit version: 0.2.4
  • Deployment type: direct_code_deploy
  • Runtime: PYTHON_3_12

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions