Skip to content

feat(sandbox): provider configs contribute default sandbox metadata - #1709

Merged
kajalj22 merged 9 commits into
mainfrom
ansubramania/sandbox-provider-default-metadata
Jun 30, 2026
Merged

feat(sandbox): provider configs contribute default sandbox metadata#1709
kajalj22 merged 9 commits into
mainfrom
ansubramania/sandbox-provider-default-metadata

Conversation

@ananthsub

@ananthsub ananthsub commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Summary

Stacked on top of #1708.

Lets a sandbox provider config contribute default sandbox metadata* so provider-identifying tags live with the provider rather than the provider-neutral agent config. A sandbox block may carry an optional default_metadata key:

sandbox:
  default_metadata: { sandbox-api: opensandbox-sdk }
  opensandbox:
    connection: { ... }

Its entries are merged into each sandbox's SandboxSpec.metadata; the agent's own sandbox_spec.metadata overrides them on conflict.

This restores the sandbox-api: opensandbox-sdk label that #1708 dropped from the agent config, now sourced from the provider config instead.

Changes

  • Add nemo_gym.sandbox.resolve_provider_metadata; exclude reserved keys (default_metadata) from resolve_provider_config.
  • mini_swe_agent_2 merges provider default_metadata into the sandbox spec metadata at runtime.
  • Add default_metadata: { sandbox-api: opensandbox-sdk } to the opensandbox provider config; document it in the README.
  • Unit tests for resolve_provider_metadata and the agent merge path.

Refs #1377

Test plan

  • uv run pytest tests/unit_tests/test_sandbox.py responses_api_agents/mini_swe_agent_2/tests/test_app.py (38 passed, 10 skipped)
  • uv run ruff check + ruff format --check clean
  • End-to-end resolution verified through GlobalConfigDictParser (provider key + default_metadata)

@copy-pr-bot

copy-pr-bot Bot commented Jun 26, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

hemildesai
hemildesai previously approved these changes Jun 27, 2026
@hemildesai
hemildesai force-pushed the ansubramania/sandbox-provider-default-metadata branch from f12573d to ce62566 Compare June 27, 2026 05:22
hemildesai
hemildesai previously approved these changes Jun 27, 2026
Sandbox providers are now defined as named blocks in their own config
files (e.g. nemo_gym/sandbox/providers/opensandbox/configs/opensandbox.yaml)
that agents reference by name (sandbox_provider: sandbox). Swapping
providers becomes swapping one config path in +config_paths, with no edits
to the agent config.

- Add resolve_provider_config to resolve a sandbox name (or an inline
  single-key mapping) to a single provider config.
- Make mini_swe_agent_2's config provider-neutral and resolve the
  reference at runtime.
- Document single / swap / multiple-sandbox usage, including distinct
  instance names for mixing providers or running two configs of the same
  provider type.

Refs #1377

Signed-off-by: Ananth Subramaniam <ansubramania@nvidia.com>
A sandbox block may carry an optional `default_metadata` key whose entries
are merged into each sandbox's spec metadata (SandboxSpec.metadata), with
the agent's own sandbox_spec.metadata taking precedence. This keeps
provider-identifying tags with the provider config instead of the
provider-neutral agent config.

- Add resolve_provider_metadata and exclude reserved keys (default_metadata)
  from resolve_provider_config.
- mini_swe_agent_2 merges provider default_metadata into the sandbox spec
  metadata.
- Restore sandbox-api: opensandbox-sdk via the opensandbox provider config.

Refs #1377

Signed-off-by: Ananth Subramaniam <ansubramania@nvidia.com>
@hemildesai
hemildesai force-pushed the ansubramania/sandbox-provider-default-metadata branch from ce62566 to 185c034 Compare June 29, 2026 16:50
Signed-off-by: Hemil Desai <hemild@nvidia.com>
Signed-off-by: Hemil Desai <hemild@nvidia.com>
hemildesai
hemildesai previously approved these changes Jun 29, 2026
Signed-off-by: Hemil Desai <hemild@nvidia.com>
Signed-off-by: Hemil Desai <hemild@nvidia.com>
hemildesai
hemildesai previously approved these changes Jun 29, 2026
Base automatically changed from ansubramania/sandbox-config-decouple to main June 29, 2026 23:47
@hemildesai
hemildesai dismissed their stale review June 29, 2026 23:47

The base branch was changed.

Signed-off-by: Hemil Desai <hemild@nvidia.com>
kajalj22 added 2 commits June 30, 2026 10:55
…provider-default-metadata

Signed-off-by: Kajal Jain <kajalj@nvidia.com>
…provider-default-metadata

Signed-off-by: Kajal Jain <kajalj@nvidia.com>
@kajalj22
kajalj22 merged commit 13ac330 into main Jun 30, 2026
16 checks passed
kajalj22 pushed a commit that referenced this pull request Jun 30, 2026
## Summary

Stacked on top of #1709. Addresses the open review thread on #1377
([here](#1377 (comment)))
asking to support an entry-points configuration so users can plug in
their own providers.

Adds a `nemo_gym.sandbox_providers` entry point group. A separate
package can publish a sandbox provider that becomes available on
install/import — no edits to the registry:

```toml
[project.entry-points."nemo_gym.sandbox_providers"]
my_provider = "my_pkg.provider:MyProvider"
```

Lookup precedence is **explicit `register_provider` > built-in loaders >
entry points**; discovery is cached. `list_providers()` now unions all
three sources.

### Changes

- `nemo_gym/sandbox/providers/registry.py`: add `ENTRY_POINT_GROUP`,
cached `_entry_point_loaders()`, and fold entry points into
`get_provider_class` / `list_providers`.
- Unit test for discovery + built-in precedence (mocked entry points).
- README: document registering a custom provider via entry points.

Refs #1377

## Test plan

- [x] `uv run pytest tests/unit_tests/test_sandbox.py
tests/unit_tests/test_opensandbox_provider.py` (23 passed, 11 skipped)
- [x] `uv run ruff check` clean

---------

Signed-off-by: Ananth Subramaniam <ansubramania@nvidia.com>
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.

3 participants