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:
- Resolve the workspace root (walk up directories until a
pyproject.toml with [tool.uv.workspace] is found).
- Expand the build context to include the workspace package directory (consistent with what
expand_source_path_for_dependencies already does for path deps).
- 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
Summary
agentcore launch(direct_code_deploy) does not resolve[tool.uv.sources]workspace dependencies when building the deployment package, causingModuleNotFoundErrorat 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.tomlfor each agent declares the dependency like this:This works perfectly for local development (
uv syncresolves the workspace member and installs it as an editable package). However, whenagentcore launchruns, it buildsdependencies.zipby executing:This bare
uv pip installcall 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:Why the pyproject.toml fallback also fails
If
requirements.txtis absent, agentcore falls back topyproject.tomland runsuv pip compile pyproject.toml. This also fails:uv pip compilerequires 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 launchtreats the agent directory as self-contained. The existingexpand_source_path_for_dependenciesutility inbedrock_agentcore_starter_toolkit/utils/paths.pyhas 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 inpyproject.toml, it should:pyproject.tomlwith[tool.uv.workspace]is found).expand_source_path_for_dependenciesalready does for path deps).uv pip compile/uv pip installso the local package is installed intodependencies.zip.Alternatively, running
uv pip compilewith 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:This is fragile, requires a manual pre-deploy step, and defeats the purpose of having a workspace.
Environment
bedrock-agentcore-starter-toolkitversion: 0.2.4direct_code_deployPYTHON_3_12